Leave a comment Posted on Tech articles

Основы работы с Git

Введение

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

Основы работы с удаленным репозитарием

git clone — создание копии (удаленного) репозитария

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

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

Клонируем репозиторий с той же машины в директорию myrepo:

git clone /home/username/project myrepo

Клонируем репозитарий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозитарий, используя протокол http:

git svn clone -s http://repo/location

-s – понимать стандартные папки SVN (trunk, branches, tags)

git fetch и git pull — забираем изменения из центрального репозитария

Для синхронизации текущей ветки с репозитарием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитария по умолчания, основной ветки; той, которая была использована при клонировании репозитария. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитария.

Возможно также использовать синонимы для адресов, создаваемые командой git remote:

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой git diff, надо создать коммит слияния с основной:

git merge username-project/master

Команда git pull сразу забирает изменения и проводит слияние с активной веткой.

Забрать из репозитория, для которого были созданы удаленные ветки по умолчанию:

git pull

Забрать изменения и метки из определенного репозитория:

git pull username-project --tags

Как правило, используется сразу команда git pull.

git push — вносим изменения в удаленный репозиторий

После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.

Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удалить ветку experimental:

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитария origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test

Работа с локальным репозиторием

Базовые команды

git init — создание репозитория

Команда git init создает в директории пустой репозиторий в виде директории .git, где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — о ходе разработки проекта:

mkdir project-dir
cd project-dir
git init

git add и git rm — индексация изменений

Следующее, что нужно знать — команда git add. Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Примеры использования:

индексация измененного файла, либо оповещение о создании нового:

git add EDITEDFILE

внести в индекс все изменения, включая новые файлы:

git add .

Из индекса и дерева проекта одновременно файл можно удалить командой git rm:

отдельные файлы:

git rm FILE1 FILE2

хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:

git rm Documentation/\*.txt

внести в индекс все удаленные файлы:

git rm -r --cached .

Сбросить весь индекс или удалить из него изменения определенного файла можно
командой git reset:

сбросить весь индекс:

git reset

удалить из индекса конкретный файл:

git reset — EDITEDFILE

Команда git reset используется не только для сбрасывания индекса, поэтому дальше ей будет уделено гораздо больше внимания.

git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы

Команду git status, пожалуй, можно считать самой часто используемой наряду с
командами коммита и индексации. Она выводит информацию обо всех изменениях, внесенных в дерево директорий проекта по сравнению с последним коммитом рабочей ветки; отдельно выводятся внесенные в индекс и неиндексированные файлы. Использовать ее крайне просто:

git status

Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.

git commit — совершение коммита

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

git commit

Если индекс не пустой, то на его основе будет совершен коммит, после чего
пользователя попросят прокомментировать вносимые изменения вызовом команды edit. Сохраняемся, и вуаля! Коммит готов.

Есть несколько ключей, упрощающих работу с git commit:

git commit -a

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

git commit -m «commit comment»

комментируем коммит прямо из командной строки вместо текстового редактора.

git commit FILENAME

внесет в индекс и создаст коммит на основе изменений единственного файла.

git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).

«Мягкий» (с ключом --soft) резет оставит нетронутыми ваши индекс и все дерево файлов и директорий проекта, вернется к работе с указанным коммитом. Иными словами, если вы обнаруживаете ошибку в только что совершенном коммите или комментарии к нему, то легко можно исправить ситуацию:

  1. git commit — некорректный коммит
  2. git reset —soft HEAD^ — переходим к работе над уже совершенным коммитом, сохраняя все состояние проекта и проиндексированные файлы
  3. edit WRONGFILE
  4. edit ANOTHERWRONGFILE
  5. git add .
  6. git commit -c ORIG_HEAD — вернуться к последнему коммиту, будет предложено редактировать его сообщение. Если сообщение оставить прежним, то достаточно изменить регистр ключа -с: 
    git commit -C ORIG_HEAD

Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.

Естественно, можно вернуться и на большую глубину коммитов,

«Жесткий» резет (ключ --hard) — команда, которую следует использовать с
осторожностью. git reset --hard вернет дерево проекта и индекс в состояние,
соответствующее указанному коммиту, удалив изменения последующих коммитов:

git add .
git commit -m «destined to death»
git reset --hard HEAD~1 — больше никто и никогда не увидит этот позорный коммит...
git reset --hard HEAD~3 — ...вернее, три последних коммита. Никто. Никогда!

Если команда достигнет точки ветвления, удаления коммита не произойдет.

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

git revert — отмена изменений, произведенных в прошлом отдельным коммитом

Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.

Отменяем коммит, помеченный тегом:

git revert config-modify-tag

Отменяем коммит, используя его хэш:

git revert cgsjd2h

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

git log — разнообразная информация о коммитах в целом

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

Простейший пример использования, в котором приводится короткая справка по всем коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении подробно узнать можно ниже, в разделе «Ветвления и слияния»):

git log

Получить подробную информацию о каждом в виде патчей по файлам из коммитов
можно, добавив ключ -p (или -u):

git log -p

Статистика изменения файлов, вроде числа измененных файлов, внесенных в них
строк, удаленных файлов вызывается ключом --stat:

git log --stat

За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ
--summary:

git log --summary

Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра его имя (кстати, в моей старой версии git этот способ не срабатывает,
обязательно добавлять » — » перед «README»):

git log README

или, если версия git не совсем свежая:

git log — README

Далее будет приводится только более современный вариант синтаксиса. Возможно
указывать время, начиная в определенного момента («weeks», «days», «hours», «s»
и так далее):

git log --since=«1 day 2 hours» README
git log --since=«2 hours» README

изменения, касающиеся отдельной папки:

git log --since=«2 hours» dir/

Можно отталкиваться от тегов.

Все коммиты, начиная с тега v1:

git log v1...

Все коммиты, включающие изменения файла README, начиная с тега v1:

git log v1... README

Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:

git log v1..v2 README

Интересные возможности по формату вывода команды предоставляет ключ --pretty.

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

git log --pretty=oneline

Лаконичная информация о коммитах, приводятся только автор и комментарий:

git log --pretty=short

Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:

git log --pretty=full/fuller

В принципе, формат вывода можно определить самостоятельно:

git log --pretty=format:'FORMAT'

Определение формата можно поискать в разделе по git log из Git Community Book
или справке. Красивый ASCII-граф коммитов выводится с использованием ключа
--graph.

git diff — отличия между деревьями проекта, коммитами и т.д.

Своего рода подмножеством команды git log можно считать команду git diff,
определяющую изменения между объектами в проекте — деревьями (файлов и
директорий).

Показать изменения, не внесенные в индекс:

git diff

Изменения, внесенные в индекс:

git diff --cached

Изменения в проекте по сравнению с последним коммитом:

git diff HEAD

Предпоследним коммитом:

git diff HEAD^

Можно сравнивать «головы» веток:

git diff master..experimental

или активную ветку с какой-либо:

git diff experimental

git show — показать изменения, внесенные отдельным коммитом

Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show:

git show COMMIT_TAG

git blame и git annotate — команды, помогающие отслеживать изменения файлов

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

git blame README

Можно указать и конкретные строки для отображения:

git blame -L 2,+3 README — выведет информацию по трем строкам, 
начиная со второй.

Аналогично работает команда git annotate, выводящая и строки, и информацию о
коммитах, их коснувшихся:

git annotate README

git grep — поиск слов по проекту, состоянию проекта в прошлом

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

Поиск слова tst в проекте:

git grep tst

Подсчитать число упоминаний tst в проекте:

git grep -с tst

Поиск в старой версии проекта:

git grep tst v1

Команда позволяет использовать логическое И и ИЛИ.

Найти строки, где упоминаются и первое слово, и второе:

git grep -e 'first' --and -e 'another'

Найти строки, где встречается хотя бы одно из слов:

git grep --all-match -e 'first' -e 'second'

Ветвление

git branch — создание, перечисление и удаление веток

Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде:

Просто перечислить существующие ветки, отметив активную:

git branch

Создать новую ветку new-branch:

git branch new-branch

Удалить ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:

git branch -d new-branch

Удалить ветку в любом случае:

git branch -D new-branch

Переименовать ветку:

git branch -m new-name-branch

Показать те ветки, среди предков которых есть определенный коммит:

git branch --contains v1.2

git checkout — переключение между ветками, извлечение файлов

Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:

checkout some-other-branch

Создаст ветку, в которую и произойдет переключение

checkout -b some-other-new-branch

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

checkout -f some-other-branch

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

checkout -m some-other-branch

Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:

Вернуть somefile к состоянию последнего коммита:

git checkout somefile

Вернуть somefile к состоянию на два коммита назад по ветке:

git checkout HEAD~2 somefile

git merge — слияние веток (разрешение возможных конфликтов)

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

Попробовать объединить текующую ветку и ветку new-feature:

git merge new-feature

В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.

Например, конфликт возник в файле TROUBLE, что можно увидеть в git status.

Произошла неудачная попытка слияния:

git merge experiment

Смотрим на проблемные места:

git status

Разрешаем проблемы:

edit TROUBLE

Индексируем наши изменения, тем самым снимая метки:

git add .

Совершаем коммит слияния:

git commit

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

git reset --hard HEAD

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

git reset --hard ORIG_HEAD

git rebase — построение ровной линии коммитов

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

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

Предположим, имеется две ветки, master и топик, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.

Вариант, в котором явно указывается, что и куда накладывается:

git-rebase master topic

на master накладывается активная в настоящий момент ветка:

git-rebase master

После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой git rebase --continue. Альтернативными выходами будут команды git rebase --skip (пропустить наложение коммита и перейти к следующему) или git rebase --abort (отмена работы команды и всех внесенных изменений).

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

git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом

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

Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:

git cherry-pick BUG_FIX_TAG

Ключ -n показывает, что изменения надо просто применить к дереву проекта без индексации и создания коммита

git cherry-pick BUG_FIX_TAG -n

Прочие команды и необходимые возможности

Хэш — уникальная идентификация объектов

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

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

найти разницу текущего состояния проекта и коммита за номером… сами видите, каким:

git diff f292ef5d2b2f6312bc45ae49c2dc14588eef8da2

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

git diff f292ef5

Иногда хватает и четырех символов:

git diff f292

Читаем лог с коммита по коммит:

git log febc32...f292

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

git tag — тэги как способ пометить уникальный коммит

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

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.

Создать «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:

git tag stable-1

Пометить определенный коммит:

git tag stable-2 f292ef5

Удалить тег:

git tag -d stable-2

Перечислить тэги:

git tag -l

Создать тэг для последнего коммита, заменить существующий, если таковой уже был:

git tag -f stable-1.1

После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff, git log и так далее:

git diff stable-1.1...stable-1

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

Создать обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария:

git tag -a stable

Создать обычный тэг, сразу указав в качестве аргумента комментарий:

git tag -a stable -m "production version"

Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

Относительная адресация

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

git diff master^

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:

найти изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки:

git diff HEAD^2

Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки нужно погрузиться:

что привнес «дедушка» нынешнего коммита:

git diff master^^

То же самое:

git diff master~2

Обозначения можно объединять, чтобы добраться до нужного коммита:

git diff master~3^~2
git diff master~6

файл .gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.

Заставить git status игнорировать определенные файлы можно, создав в корне или глубже по дереву (если ограничения должны быть только в определенных директория) файл .gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов определенного формата.

Пример содержимого такого файла:

#комментарий к файлу .gitignore
#игнорируем сам .gitignore
.gitignore
#все html-файлы...
*.html
#...кроме определенного
!special.html
#не нужны объектники и архивы
*.[ao]

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

Серверные команды репозитория

; git update-server-info : Команда создает вспомогательные файлы для dumb-сервера в $GIT_DIR/info и $GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки и пакеты есть на сервере.

; git count-objects : Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
; git gc : Переупаковка локального репозитория.

Рецепты

Создание пустого репозитория на сервере

repo="repo.git" 
mkdir $repo
cd $repo
git init --bare
chown git. -R ./
cd ../

Импорт svn репозитория на Git-сервер

repo="repo.svn" 
svnserver="http://svn.calculate.ru" 
git svn clone -s $svnserver/$repo $repo
mv $repo/.git/refs/remotes/tags $repo/.git/refs/tags
rm -rf $repo/.git/refs/remotes
rm -rf $repo/.git/svn
mv $repo/.git $repo.git
rm -rf $repo
cd $repo.git
chown git. -R ./
cd ../

Ссылки

Leave a comment Posted on Tech articles

Как я внедрял первое правило ведения бизнеса в России

«1. Держите сервера за границей»
(с) 9,5 правил ведения безопасного бизнеса в России 

Вводная часть.

Мы — маленькая компания из 10 сотрудников, половина из которых периодически работает удаленно.
Что мы имели изначально: сервер с Windows и терминальным доступом, который стоял в офисе. У всех пользователей были ноутбуки. Никакой особо конфиденциальной информации у нас нет, за исключением важной для бизнеса информации.
В один прекрасный момент меня окончательно «добила» паранойя и было принято решение вынести сервер за пределы офиса.

1) Мы арендовали два сервера: один в Германии, второй — в Нидерландах.
Конфигурации одинаковые: Intel Xeon Quad Core E3-1230 3.20 GHz / 8GB / 2x 1TB.
Обязательными условиями были: IP-KVM 24×7, гарантия ответа техподдержки до 4 часов круглосуточно, гарантия замены сервера на следующий рабочий день (NBD) и безлимитный трафик.
Дополнительные требования к ПО: Windows 2008 standard, Windows 2008 enterprise, терминальные лицензии и MS Office (Word, Excel, PowerPoint)
Эти пожелания и определили достаточно нескромный бюджет: 756 евро/мес.

Хостеров оставим неназванными. Могу только сказать, что из-за желания платить через Webmoney (т.е. не кредитными картами), пришлось обратиться к реселлерам.

2) Настройка обоих серверов на начальном этапе была полностью идентичной. После получения доступа к серверам, весь первый день был потрачен на апдейт ОС. После был установлен Hyper-V.
Сразу же была создана виртуалка на CentOS, которая и стала роутером: именно у неё был «белый» IP. Все остальные машины (в том числе хост-система) работали на «серых» адресах.
Для проведения этого фокуса с IP, нам пригодился постоянно подключенный IP-KVM. В данном случае — встроенный IPMI и iLo на каждом из серверов.
На роутере был поднят Open VPN-сервер, «снаружи» был доступен только он. Все остальные порты были закрыты.
Также на роутере поднят NAT и proxy-сервер.

3) На первом сервере на всю доступную память была создана виртуалка с Windows 2008 Standard, которая стала нашим новым офисным сервером.
7 ГБ для одновременной работы 10 человек в терминале – более чем комфортные условия. Интернет пользователям офисного сервера доступен только через прокси.
Работает Dr.Web, лицензии на который нам достались по подписке от сети, к которой подключен наш офис.
Стандартный набор офисного софта: MS Office, Acrobat Reader, PDF Creator, WinRAR, InfranView, KeePass, Chrome, Firefox.
Чтобы пользователи не путались, всем в автозагрузку был вложен файл Bginfo, который меняет цвет рабочего стола и пишет на нем, что это за сервер.

4) На втором сервере все немного интересней.
На хост-сервере стоит Windows 2008 Enterprise, которая позволяет бесплатно установить до 4-х виртуалок с Windows 2008 Standard.
Таким образом, это, по сути, сервер для бухгалтера: тут работают четыре виртуалки — CRM/биллинг, 1C8 (на нее переходим), 1C7 (с ней работаем), клиент-банк.
Все четыре сервера отделены друг от друга: они находятся в разных виртуальных сетях Hyper-V, которые не могут видеть друг друга.
Так сделано для того, чтобы в ситуации, когда какая-то из машин подхватит какую-то заразу, заражение не распространилось дальше неё.
С этих же машин отправляем отчеты в налоговую через MeDOC и “Податкову звiтнiсть”. Налоговая видит, что отчеты приходят из IP нашего офиса а не из Европы, так как трафик с «бухгалтерских» серверов маршрутизируется через VPN-туннель в офис.
Так же, как и на офисной виртуалке, на серверах с 1С, интернет доступен через прокси, работают Dr.Web’ы и стандартный софт.
В 1С 7ой ключ работает через Usb-over-network, с 1С 8 используем программный ключ.
На сервере клиент-банка интернет отключен: доступ есть только к серверам банков. Банк также видит наш офисный IP а не реальный IP сервера.

5) Все эти серверы доступны через удаленный рабочий стол (RDP) после авторизации на Open VPN-сервере (любом из двух).
И еще один плод моей паранойи: при подключении к Open VPN-серверу невозможно увидеть ни один сервер в своей сети.
По RDP на серверы можно зайти только через нестандартный порт, который «прокидывается» (DNAT) на RDP-порт соответствующей виртуалки.

6) В офисе у нас стоит Wi-Fi роутер D Link DIR-320. Мы перепрошили его, после чего настроили на нем OpenVPN-клиент.
В DIR-320 включен USB-принтер, на который через туннель могут печатать все виртуалки.
Сотрудники из офиса могут работать, ничего не меняя на своих ноутбуках.
Сотрудникам, которые хотят поработать удаленно, выдали ключи Open VPN и следующие инструкции: как настроить туннель на MacOS/Windows, как зайти на удаленный рабочий стол, как печатать на офисный принтер, как печатать на домашний принтер и тому подобное.

7) Самое важное — бекап.
Так как на хост-системах ничего кроме Hyper-V нет, их не бекапим.
В пятницу днем всем сотрудникам приходит рассылка (напоминание о событии от Google Calendar) с просьбой не забыть закрыть все приложения и сохранить все документы.
В ночь с пятницы на субботу Power Shell–скрипт выключает все виртуалки, копирует их VHD-образы в отдельную папку, а откуда копирует на дублирующий сервер через VPN-туннель + на мой сервер в Украине.
Но это только половина дела.
Каждый день на всех виртуалках запускается скрипт, который архивирует изменившиеся за сутки данные; а каждую неделю – архивирует все данные пользователей (действительно все – от документов до 1С-баз).
Архивация происходит по мотивам этой инструкции:habrahabr.ru/blogs/personal/82185/, но архивы мы делаем запароленными, многотомными и с добавлением информации для восстановления. Архивы складываются в премиум-аккаунты DropBox и Google Drive и через эти сервисы попадают на оба сервера (+ директору на ноутбук).

Что имеем в итоге:
— По запросу я могу восстановить любой документ за любой день.
— Все архивы под паролем из сотни случайных символов. Даже если DropBox кому-то опять покажет все свои файлы, мой архив вскрыть будет крайне непросто.
— При каком-либо форс-мажоре с одним из ДЦ, я, чуть меньше чем за час, смогу запустить копию сервера недельной давности на другом сервере в другой стране + накатить изменения из архивов.

Все описанное работает у нас уже почти год. Особых нареканий нет, разве что апдейт ПО на четырех серверах занимает вчетверо больше времени :).
Данные из бекапных архивов пару раз восстанавливал по требованию – работает как часы.
Для теста имитировал несколько раз отключение ДЦ: поднимал все серверы из бекапа на одном из серверов. Все работает, разве что для 1С8 с программным ключом важно сделать полностью аналогичную конфигурацию на новом сервере.
У бухгалтера однажды “слетел” ноутбук, – работу восстановили за пол часа, просто выдав новый и настроив ярлыки для подключения к серверам.
Дата-центры были недоступны несколько раз на пол-часа из-за апгрейда маршрутизаторов, но в рабочее время подобного ни разу не было.
Также однажды была атака на ДЦ в Нидерландах: все «лагало» около часа в рабочее время.
Теоретически можно было бы еще наворотить шифрованные ФС и разнести серверы по разным континентам, но в нашем случае я не вижу в этом никакого смысла.

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

http://habrahabr.ru/post/157899/#habracut

Leave a comment Posted on Tech articles

Cisco K9

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

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

Приставка K9 в артикуле любого устройства Cisco говорит о НАЛИЧИИ в этом устройстве ЛЮБЫХ алгоритмов шифрования, без конкретизации их стойкости. Именно поэтому, почти во всех устройствах Cisco в артикуле присутствует окончание K9. IP телефоны Cisco используют криптографию для безопасного подключения через публичную IP сеть к IP АТС и защите от перехвата речевой информации.WI-FI точки доступа с помощью протокола WPA обеспечивают установление защищенного беспроводного подключения . В маршрутизаторах Cisco и в межсетевых экранах Cisco ASA заложена функция создания шифрованного соединения через IP сети – IPSec VPN. Использование IPSec VPN в содружестве со стойким алгоритмом шифрования информации 3DES обеспечивает достаточно серьезную защиту сети на публичных каналах связи. Продукция Cisco имеющая в себе 3DES шифрование запрещена к ввозу на территорию Российской Федерации без лицензии. Поэтому любой маршрутизатор Cisco c является криптографическим средством, имея в арсенале протокол 3DES, наличие которого приравнивает его к шифровальному средству. Ввоз, обслуживание, реализация шифровальных средств на территории России — лицензируемая деятельность. Чтобы обеспечить пользователям свободный доступ к сетевым технологиям и современным решениям по защите сети компания Cisco выпустила модель К8. Это технически и физически то же самое устройство, но с вырезанными функциями 3DES из операционной системы устройства IOS. Для создания защищенного соединения и удаленного доступа в устройствах, поставляемых российским потребителям, присутствует только DES или AES шифрование.

Что такое Cisco PCI? Маршрутизаторы Cisco K9 как средство защиты информации в банковских сетях

Запрет к открытой поставке в Россию таких устройств сетевой защиты как маршрутизаторы и межсетевые экраны Cisco с 3DES шифрованием вызвал значительный резонанс. Подобные сетевые устройства защиты в большинстве своем использовались не частными лицами, а бизнес структурами, финансовыми и производственными предприятиями. Наибольшая потребность в надежных VPN устройствах у финансовых организаций – банков. Применение стойких алгоритмов защиты в банковских сетях гарантирует сохранение ценной информации – финансовых данных и личных данных клиентов. Нехватка сетевых средств защиты информации в продаже со вступлением новых законов в силу приостановила рост и развитие финансовых институтов, ввиду отсутствия необходимых устройств защиты сети на российском рынке. В значительной степени это было связано с расширением сети банкоматов — выросло потребление маршрутизаторов младшей серии СISCO881-K9, СISCO861-K9, которые в большинстве использовались банками для организации безопасного подключения мобильного терминала (банкомата) к банковской сети. Понимая сложность ситуации правительство пошло на помощь. Устройства, специально разработанные для защиты финансовой информации платежных систем имеют в артикуле сокращение PCI – Payment Card Industry, означающее, что данное устройство сертифицировано MasterCard, Visa, Amex, JCB для организации доступа к платежным системам. Именно поэтому устройства PCI-K9 поставляются на российский рынок, продаются, НО, приобрести подобные устройства имеет право только финансовое учреждение с лицензией, а продавать – организация имеющая лицензию на распространение криптографических средств.

Таким образом, подводя итог анализа средств Cisco K9 и Cisco K8 для защиты сети:

1. Все устройства Cisco с артикулом K9 в окончании на официальном рынке России –имеют криптографию, разрешенную ко ввозу на территорию России без лицензии и разрешены к открытой продаже.

2. Сетевые устройства Cisco, имеющие в артикуле K8 – устройства, с усеченными функциями по криптографии, которые в большинстве касаются отсутствием поддержки протокола 3DES, но при этому поддерживают IPSEC VPN на уровне AES, DES.

3. Устройства PCI – имеют стойкую криптографию (3DES), но продаются только банкам, только организациями, имеющими на это право (имеющими лицензию ФСБ на распространение криптографических средств).

Leave a comment Posted on Tech articles

Межсетевой экран Cisco ASA 5505

Межсетевые экраны Cisco ASA – современные функциональные устройства для защиты локальных сетей. Основная функция межсетевого экрана (firewall) — защита сети от вторжений, вирусов, спама, шпионских программ, контентная фильтрация трафика пользователей. Построенные на базе аппаратной платформы сетевые экраны Firewall Cisco ASA обеспечивают высокую надежность, производительность в задаче обеспечения безопасности ЛВС от внешних атак.

Межсетевой экран Cisco ASA 5505

Сетевой экран Cisco ASA 5505 — самое младшее устройство в серии Cisco ASA, однако этот брандмауэр имеет очень высокую производительность и эффективность в защите локальной сети от внешних атак. Межсетевой экран Cisco ASA 5505 — это производительный файрвол (брандмауэр), обеспечивающий до 150 Мбит/с* транзитного трафика. Сетевой экран ASA 5505 работает на скорости до 100 Мбит/с* при организации VPN доступа. В первую очередь устройство ориентированно на обеспечение сетевой безопасности пользователей сегмента малого бизнеса в силу простоты эксплуатации и низкой цены. Помимо функций межсетевого экрана Cisco ASA 5505 выполняет NAT трансляцию для совместного доступа пользователей к сети Интернет, является IPSec VPN сервером для безопасного удаленного доступа к локальным ресурсам. Огромным преимуществом является наличие встроенного 8-и портового коммутатора, при этом 2 порта имеют поддержку PoE, что обеспечивает простоту подключения IP камеры, WI-FI точки доступа или IP телефона.

Модификации межсетевого экрана Cisco ASA5505

1. ASA5505-K8 — стандартная комплектация
Межсетевой экран Cisco ASA в этой конфигурации обеспечивает обработку до 10000 одновременных сессий пользователей, позволяет создать до 10 IPSec VPN туннелей, обеспечивает защиту для 10-и пользователей, имеет возможность создания до 3-х VLAN, путем назначения нужных портов внутреннего коммутатора в нужную группу VLAN интерфейса. Не поддерживает создание 802.1Q транк порта

2. ASA5505-50-BUN-K8 — конфигурация брандмауэра с расширенным количеством пользователей.

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

3. ASA5505-SEC-BUN-K8 – конфигурация Security Plus c поддержкой 50-и пользователей, 25 IPSec VPN подключений, до 20 VLAN 802.1Q TRUNK на портах коммутатора, включающая функцию DMZ

4. Максимальная конфигурация ASA5505-UL-BUN-K8 — в этой конфигурации устройство не имеет ограничений на кол-во пользователей, имеет Security Plus лицензию со всем функциями платформы

5. ASA5505-50-AIP5-K8 – конфигурация на 50 пользователей, со встроенным модулем AIP-SSC-5, который обеспечивает аппаратное ускорение межсетевого экрана и выполнение функции IPS — защиту сети от шпионских программ, вирусов. Имеет все функции Security Plus

6. ASA5505-SSL10-K8 – версия, с возможностью использования SSL для организации удаленных защищенных подключений пользователей. Основной плюс использования SSL для создания удаленных VPN подключений – поддержка протокола SSL практически всеми устройствами, отсутствие необходимости в установке отдельного клиента для IPSec.

Опции и пакеты расширения для межсетевого экрана Cisco ASA5505

ASA5505-SEC-PL – Security Plus лицензия, снимающая ограничение и позволяющая использовать порты встроенного коммутатора в режиме до 20 VLAN 802.1Q TRUNK, организовывать до 25-и IPSec VPN подключений, включающая функцию DMZ для стандартных версий межсетевого экрана

ASA5505-RACK-MNT – набор для монтажа межсетевого экрана ASA 5505 в стандартную телекоммуникационную стойку 19”. Комплект позволяет установить до 2-х устройств Cisco ASA 5505. Включает в себя полку размером 2Uс необходимыми кронштейнами и крепежом

ASA5505-SW-10-50 – лицензия расширения количества защищаемых экраном ASA 5505 пользователей с 10 до 50 ASA5505-SW-10-UL –лицензия снятия всех ограничений количества защищаемых сетевым экраном ASA 5505. Применяется для стандартной версии межсетевого экрана

ASA5505-SW-50-UL – лицензия снятия всех ограничений количества защищаемых экраном ASA 5505. Применяется при модернизации любой 50-и пользовательской версии ASA5505 ASA5505-SSL10-K8 – лицензия включения поддержки SSL VPN на 10 пользователей ASA5505-SSL25-K8 – лицензия включения поддержки SSL VPN на 25 пользователей

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

Leave a comment Posted on Tech articles

Базовые сервисы технологии MPLS


MPLS (англ. Multiprotocol Label Switching — мультипротокольная коммутация по меткам) — механизм передачи данных, который эмулирует различные свойства сетей с коммутацией каналов поверх сетей с коммутацией пакетов.

MPLS работает на уровне, который можно было бы расположить между вторым (канальным) и третьим (сетевым) уровнями модели OSI, и поэтому его обычно называют протоколом второго с половиной уровня (2.5-уровень). Он был разработан с целью обеспечения универсальной службы передачи данных как для клиентов сетей с коммутацией каналов, так и сетей с коммутацией пакетов. С помощью MPLS можно передавать трафик самой разной природы, такой как IP-пакеты, ATM, SONET и кадры Ethernet.

  1. MPLS ATM интеграция
  2. MPLS QoS
  3. MPLS Traffic Engineering (TE)
  4.   Traffic Engineering (TE)
  5.   Fast Re Route (FRR)
  6. MPLS L3 VPN
  7. MPLS L2 VPN
  8.   Point-to-Point VPN (AToM, EoMPLS)
  9.   Multi-Point VPN (VPLS)
  10. GMPLS
  11. Заключение

Основным преимуществом MPLS считается ускорение скорости продвижения пакетов (IP) в ядре сети. Однако существуют и другие, не менее важные, приложения для этой технологии.

MPLS ATM интеграция

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

MPLS QoS

MPLS не определяет новую QoS архитектуру, а базируется на использовании широко известной и зарекомендовавшей себя на практике IP QoS парадигмы.

Для IP QoS определено две модели: IntServ и DiffServ.

IntServ определяет потоковый QoS и использует RSVP для сигнализации.

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

MPLS QoS использует DiffServ подход, помещая необходимую маркировку в заголовке. Эквивалентом DSCP метки может являться трехбитовое Experimental поле в MPLS.

Кроме того, реализация TE в принципе может автоматически выполнять функции QoS.

MPLS Traffic Engineering (TE)

Traffic Engineering (TE).

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

Обычные протоколы маршрутизации (IGP протоколы IS-IS, OSPF) предоставляют ограниченные возможности по управлению трафиком на основе метрик составляющих сеть линков.

Основной механизм TE в MPLS – использование однонаправленных туннелей (MPLS TE tunnel) для задания пути прохождения определенного трафика. Например, для одного вида трафика, например высокоприоритетного голосового можно проложить один путь через сеть, а для низкоприоритетного – другой. Так как туннели – однонаправленные, то обратный путь может быть совершенно другим.

Технологически MPLS TE основывается на формировании маршрутов прохождения пакетов (LSP) через сеть с помощью механизма создания туннелей (MPLS Tunnel), который в свою очередь базируется на стекировании меток (Labels Stack).

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

Однако полный комплекс мероприятий MPLS TE выглядит несколько сложнее и условно разбивается на следующие стадии (этапы).

1. Организация MPLS домена.

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

2. Наложение ограничений.

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

3. Изучение параметров сетевой среды.

Для распространения информации о каналах (атрибутах линков) используется механизм расширения протоколов маршрутизации (Link State Protocols: IS-IS, OSPF).

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

4. Вычисление путей прохождения трафика в соответсвии с административными требованиями и возможностями сети.

На граничных входных (по отношению к потоку трафика) маршрутизаторах выполняется специальный алгоритм Constrained Base Algorithm, учитывающий политику выбора лучшего пути для LSP туннеля (то есть набор роутеров, через которые передавать трафик): как возможности каналов, так и административные требования (границы MPLS домена, полоса пропускания). Алгоритм перебирает линки (их свойства) и в итоге по мерикам вычисляет маршруты (пути) прохождения трафика с учетом накладываемых ограничений. То есть в итоге на входном маршрутизаторе (head-end) конструируются требуемые LSP до выходного маршрутизатора (head-tail) в соответствии с наложенными требованиями на прохождение трафика между ними.

5. Установление путей.

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

Сегодня известно два таких протокола: RSVP-ext и CR-LDP.

MPLS поддерживает два вида явных путей: строгий (strict) с определением всех промежуточных узлов и свободный (loose), когда задается только их часть.

С помощью RSVP ext устанавливается LSP (TE Tunnel) вдоль вычисленного пути. Это автоматическая установка. RSVP использует PATH и RESV сообщения для проброса LSP вдоль рассчитанного пути. При этом согласуются еще и параметры полосы пропускания (Admission Control).

6. Установка маршрутов с учетом туннелей TE.

IGP устанавливает маршрут с учетом наличия туннелей (как tunnel интерфейсы). В итоге процесс маршрутизации на входном маршрутизаторе (head-end) просто оперирует LSP туннелями как интерфейсами. А в таблице маршрутов head-end будет маршрут к head-tail с next-hop – TE tunnel.

7. Продвижение пакетов.

С помощью механизма MPLS (Label Stacking) происходит обеспечение необходимого туннелирования и продвижение пакетов.

Fast Re Route (FRR)

Технология Fast ReRoute (FRR) позволяет временно направить трафик по запасному каналу в обход отказавшего линка на участке пути LSP до тех, пор пока head-end сможет изменить весь LSP. Время восстановления порядка 50 ms. Предварительно конфигурируется запасной туннель (backup tunnel). Контролируется маршрутизаторами на концах отказавшего линка. Используется стекирование меток в случае обхода проблемного участка.

MPLS L3 VPN

MPLS позволяет создавать виртуальные частные сети Layer 3, не прибегая к туннелированию (GRE) и шифрованию (IPsec).

MPLS VPN сеть делится на две области: IP сети клиентов и магистраль провайдера. Классическая конструкция MPLS L3 VPN состоит из следующих компонентов: граничные маршрутизаторы провайдера PE, обращенные к клиентскому оборудованию CE, соединены между собой P маршрутизаторами в MPLS домене. В принципе, P маршрутизаторов может и не быть, необходимо чтобы обеспечивалась связность между PE.

MPLS L3 VPN инфраструктура предполагает обеспечение изоляции распределенных клиентских IP сетей в рамках VPN. То есть обеспечивается только обмен пакетами между IP сетями одной VPN.

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

Каждая VPN логически связана с одним или долее комплексов маршрутизации и пересылки (VPN Routing and Frowarding instance – VRF). VRF определяет членство в VPN подсети за узлом CE, подключенного к PE. Интерфейсы PE маршрутизаторов, обращенные к CE, логически связаны с индивидуальными VRF.

Экземпляр VRF состоит из таблицы маршрутизации (IPv4), получаемой из нее CEF, набора интерфейсов, использующих VRF и других данных. VRF таблицы IP маршрутизации используются для обмена информацией о маршрутах только внутри VPN сети и не выходят за границу VPN, то есть извне невозможно послать пакет на маршрутизатор, находящийся внутри VPN (этот маршрут попросту неизвестен). В итоге VRF представляет собой quot;виртуальный маршрутизаторquot; внутри PE.

В рамках MPLS L3 VPN в VPN включается IPv4 клиентские подсети. В пределах одной VPN не допускаются пересекающиеся IPv4 адреса. Однако в разных VPN это допустимо. Отсюда потенциальная неоднозначность для PE маршрутизатора: разные VRF могут содержать одинаковые IPv4 адреса. Для получения уникальных адресов (и соответственно маршрутов), называемых VPN-IPv4, используется идентификатор VPN- Route Distinguisher (RD). VPN-IPv4 получается добавлением к IPv4 идентификатора RD. В итоге PE оперирует уникальными VPN-IPv4.

Для обмена маршрутной информацией между VRF разных PE используется MP-BGP протокол. MP-BGP оперирует VPN-IPv4 маршрутами.

Таким образом, с помощью MP-BGP получается виртуальная связь между PE (между VRF одинаковых VPN). Для выполнения политики экспорта/импорта дополнительно вводится понятие адресата маршрута — Route Target (RT).

В итоге получается следующая схема. Каждый клиентский сайт (интерфейс на PE) имеет свою VRF (таблицу IPv4 маршрутизации). PE может узнать IP префикс клиента разными способами (статическая конфигурация, BGP, RIP, OSPF, IS-IS). PE помещает IPv4 маршрут клиента в VRF данного сайта. Кроме того, с помощью заранее выбранного идентификатора VPNов, в которые входит данный сайт, IPv4 маршруты (префиксы) преобразуются в VPN-IPv4 маршруты и помещаются в MP-BGP. MP-BGP согласно политике импорта/экспорта связывает между собой все PE маршрутизаторы (их VRF). В итоге в VRFы разных PE, но принадлежащих одной VPN, попадают все маршруты из данной VPN. Причем в записях VRF Next Hopами являются PE, как будто они связаны между собой (виртуально посредством MPLS).

Реальная передача пакетов (коммутация) происходит при помощи MPLS. MPLS метки используются следующим образом: пакет содержит два уровня меток (используется стек). Первая метка направляет пакет к требуемому PE (next hop), а вторая указывает комплекс VRF, логически связанный с выходным интерфейсом CE маршрутизатора пункта назначения.

Рассмотрим на примере прохождение пакетов в MPLS L3 VPN.

Предположим, CEx посылает пакет для CEy. От CEx к PEx приходит пакет с DST=NETY (сеть за CEy) и без меток. Данный пакет приходит с определенного интерфейса и поэтому обрабатывается конкретной VRFx. В VRFx есть маршрут к NETY с NEXT-HOP – PEy и метка VPN (метка L1 для попадания в необходимую VRFy на PEy). Метку для достижения PEy PEx ищет в своей глобальной таблице маршрутизации. Таким образом, PEx отправляет в сторону PEy пакет со стеком меток: L2 для достижения PEy как NEXT-HOP и L1 для достижения нужной VPN (VRFy) на PEy. По метке L2 пакет доходит до PEy и она там удаляется. PEy по метке L1 выясняет какой VRF пользоваться для достижения NETY. В VRFy для NETY указан соответствующий интерфейс PEy-CEy. В сторону CEy пакет уходит без меток в виде IPv4.

MPLS L2 VPN

Современные реалии таковы, что конечный потребитель телекоммуникационных услуг начинает мыслить абстрактно и потребности свои выражает в категориях Metro (Ethernet) а не WAN (IP). Поэтому наиболее актуальной становится задача построения VPN Layer 2. Используя MPLS, данную задачу можно решить несколькими способами. Рассмотрим некоторые из них.

Point-to-Point VPN (AToM, EoMPLS)

Для создания VPN Layer 2 по схеме точка-точка (point-to-point) разработана технология Any Transport Over MPLS (AToM), обеспечивающая передачу Layer 2 фреймов через MPLS сеть. AToM – это интегральная технология, включающая Frame Relay over MPLS, ATM over MPLS, Ethernet over MPLS.

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

AToM использует непосредственные LDP сессии между граничными маршрутизаторами провайдерской сети (PE) для установления и поддержки соединений. Непосредственное продвижение пакетов происходит с использованием стекирования меток MPLS, когда одна метка (Top) соединяет граничные маршрутизаторы, а вторая (Bottom) – определяет непосредственно VPN клиента (интерфейс на PE маршрутизаторе).

Так как наиболее востребованной в настоящее время является технология Ethernet over MPLS (EoMPLS), то детали функционирования AToM рассмотрим на ее примере.

EoMPLS инкапсулирует Ethernet фреймы в MPLS пакеты и использует стек меток для продвижения через MPLS сеть. На каждом PE-CLE (Customet Leading Edge) организуется Virtual Circuit (VC). Обязательно устанавливаются прямые LDP сессии между входным и выходным PE-CLE для обмена информацией о VC. Каждая VC состоит из двух однонаправленных LSP.

Непосредственно передача пакетов использует стек меток Верхняя метка (Top Label), называемая еще Tunnel Label, используется для достижения выходного (Egress) PE-CLE. Нижняя метка (Bottom Label), называемая VC Label, используется для определения интерфейса на PE-CLE. VC Label обеспечивается Egress PE-CLE для Ingress PE-CLE для направления трафика в нужный интерфейс на Egress PE-CLE. VC Label отождествляется с VC ID и устанавливается на этапе VC setup.

Multi-Point VPN (VPLS)

С целью преодоления ограничений point-to-point VPN разработана технология Virtual Private LAN Service (VPLS). VPLS – Layer 2 VPN технология, обеспечивающая многоточечные соединения (Multipoint Services) поверх пакетной сетевой инфраструктуры. VPLS дают возможность объединения распределенных локальных сетей в единую сеть.

Для потребителя сеть провайдера услуг выглядит как виртуальный Ethernet свич. При этом сеть оператора связи абсолютно прозрачна и не видна для сети заказчика.

Логическая структура VPLS выглядит следующим образом.

Для каждого VPN на каждом PE выполняется Virtual Switching Instance (VSI), которая обеспечивает forwarding decision для каждой VPLS. Ethernet фреймы коммутируются между PE устройствами, используя VSI. В принципе VPLS расширяет модель AToM до многоточечных соединений, используя те же методы инкапсуляции.

Дальнейшим развитием масштабирования данной технологии является Hierarchical VPLS (H-VPLS). H-VPLS подразумевает декомпозицию PE устройства на два User-Facing PE (u-PE) и Network PE (n-PE).

Отличие VPLS от AToM в том, что AToM – p-t-p L2 сервис, а VPLS – multipoint.

В тоже время MPLS L3 VPN тоже multipoint, но ограничен IP трафиком. VPLS же L2 сервис и может поддерживать несколько высокоуровневых протоколов.

GMPLS

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

Заключение

Краткое обобщающее содержание выше изложенного.

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

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

MPLS QoS использует DiffServ модель и принципиально ничем от нее не отличается.

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

MPLS Layer 3 VPN – технология объединения IP подсетей клиентов с полной изоляцией их друг от друга.

MPLS Layer 2 VPN позволяет объединять клиентские подсети на втором уровне. Может представлять собой виртуальный пачкорд (Point-to-point, AToM) или виртуальный свич (Multipoint, VPLS).

Общие выводы.

В настоящее время MPLS знаменует собой победу IP как универсального транспорта для всех видов приложений.

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

(Источник)

Leave a comment Posted on Tech articles

QoS. Качество обслуживания в операторских сетях

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

Понятие качества обслуживания (QoS)

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

– Диапазон времени сетевой достижимости между входной и выходной точкой сети – это сетевая доступность.

Доступность сервиса

– это диапазон времени, в течение которого этот сервис доступен между определенными входной и выходной точками с параметрами, оговоренными в соглашении об уровне обслуживании (SLA).
Потери

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

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

-это разница между сквозным временем задержки, которая возникает при передаче по сети разных пакетов. Так, например, если для передачи одного пакета по сети требуется 100 мсек, а для передачи следующего пакета — 125 мсек, то колебание задержки составит 25 мсек.

У каждого терминала VoIP (голос поверх IP) или «видео поверх IP» имеется буфер колебаний задержки (jitter buffer). Этот буфер используется для выравнивая колебаний задержки голосовых пакетов. Буфер колебаний задержки может быть динамическим и адаптивным и может регулировать время задержки пакетов в пределах 30 мсек. Если колебания задержки будут превышать возможности буфера, то он будет работать с недогрузкой (under-run) или перегрузкой (over-run). И то и другое оказывает отрицательное влияние на качество связи.
Пропускная способность

– это доступная пользователю полоса пропускания между двумя точками присутствия оператора.

Инструменты классификации и маркировки пакетов

Для любого правила QoS нужно прежде всего определить трафик, имеющий особые требования. Инструмент классификации помечает пакет или фрейм определенным значением. Эти значения меток позволяют разграничить разные типы трафика и применить к ним разные правила обработки очередей (CBWFQ, MDRR и т.д.). Классификация и маркировка производится на основе анализа следующих параметров:

  • параметры Уровня 2 (биты класса услуг [CoS] 802.1Q, значение экспериментальных бит MPLS);
  • параметры Уровня 3 (биты IP Precedence [IPP], кодовые точки дифференцированных услуг [DSCP Code-Points], IP-адреса источника и пункта назначения);
  • параметры Уровня 4 (порты TCP или UDP);
  • параметры Уровня 7 (подписи приложений).

Только после полной идентификации трафика к нему можно применять QoS правила (policies). Рекомендуется идентифицировать и помечать трафик (с помощью DSCP) как можно ближе к источнику. Периферийная часть сети, где происходит прием (или отклонение) классификации пакетов, называется «границей доверия» (trust boundary). Если метки проставлены правильно, то промежуточным участкам сети не приходится повторно идентифицировать трафик. На этих участках просто выполняются правила QoS, определенные проставленными ранее метками DSCP. Такой подход упрощает сетевое управление и сокращает нагрузку на процессоры.

Классификация должна производиться на сетевой периферии, обычно на оборудовании в распределительных шкафах, на IP-телефонах или на других терминалах голосовой связи. Однако, не рекомендуется доверять маркировке сделанной приложениями на персональных компьютерах, так как возможны злоупотребления со стороны пользователей. Классификация осуществляется с помощью списков доступа (ACL), DSCP или MPLS EXP.

Для маркировки трафика могут использоваться следующие механизмы:

  • 802.1Q/p классы услуг (CoS) – Ethernet фреймы могут помечаться с помощью бит в заголовке второго уровня с использованием 802.1p бит приоритета в заголовке 802.1Q. Размер поля 802.1p — 3 бита, таким образом только восемь классов сервиса (0-7) доступны для маркировки Ethernet фреймов второго уровня.
  • Байт типа сервиса -IP Type of Service (ToS) — В связи с тем, что в процессе прохождения пакетов от источника к назначению часто меняется среда второго уровня, более универсальный метод маркировки заключается в использовании заголовка третьего уровня. Второй байт заголовка IPv4 пакета – это байт TOS. Первые три бита байта TOS называются битами IPP. IPP, также как и CoS биты 802.1p, позволяют пометить пакет только восемью значениями (0-7). Обычно IPP биты устанавливаются соответствующим образом:
  • IPP значения 6 и 7 резервируются для сетевого управляющего трафика (например, протоколов маршрутизации);
  • IPP значение 5 рекомендовано для речевого трафика;
  • IPP значение 4 используется совместно трафиком видеоконференций и потокового видео;
  • IPP значение 3 предназначено для сигнализации вызовов;
  • IPP значения 1 и 2 могут использоваться для приложений данных;
  • IPP значение 0 – маркировка по умолчанию.
Многие корпоративные пользователи считают, что IPP маркировка очень ограничена и не позволяет иметь большое число классов сервиса. В этом случае применяется 6-битная модель маркировки DSCP (64 значения).
  • DSCP — значения DSCP могут быть выражены в цифровой форме или с использованием специальных ключевых слов, называемых поведением сетевых участков (PHB — Per-Hop Behavior). Определено три класса DSCP маркировки: по возможности (BE – best effort или DSCP 0), гарантированная доставка (Assured Forwarding, AFxy) и срочная доставка (Expedited Forwarding – EF). В дополнение к этим трем определенным классам существуют коды селектора классов (class selector code points), которые обратно совместимы с IPP (CS1-CS7 идентичны значениям 1-7 IPP). Эти PHB описаны в RFC 2547, 2597 и 3246, соответственно. Определено четыре класса гарантированной доставки, они начинаются с AF и далее две цифры. Первая цифра определяет AF класс и принимает значения от 1 до 4. Вторая цифра определяет уровень вероятности сброса пакета в пределах каждого класса и принимает значения от 1 (минимальная вероятность сброса) до 3 (максимальная вероятность сброса). Значения DSCP могут быть выражены в десятичном формате или с использованием ключевых слов DSCP. Например, DSCP EF аналогично DSCP 46, а DSCP AF31 аналогично DSCP 26.
  • MPLS EXP — Биты MPLS EXP – это три бита в MPLS метке, содержащие индикатор QoS. По умолчанию, во время импозиции (добавления) метки в значение MPLS EXP записывается значение поля IPP IP пакета. Размер поля позволяет использовать до восьми QoS маркировок против 64 для DSCP. Значения EXP бит используются для определения PHB на узлах MPLS сети и могут использоваться для обеспечения прозрачности переноса значений IPP/DSCP в пакетах клиента в случае применения MPLS методов тунелирования Diffserv (MPLS DiffServ Tunneling Modes).

Инструменты планировки

Инструментами планировки (scheduling) называются средства, которые определяют, как фрейм или пакет будет выходить из сетевого узла. В любом случае, когда пакеты входят в устройство быстрее, чем выходят из него (т.е. в случае несовпадения скоростей на входе и выходе) возникает «точка переполнения» или «узкое место». У сетевых устройств имеются буфера, которые позволяют приоритетным пакетам поступать на выход быстрее, чем не приоритетным. Этот подход называется «очередностью» (queuing).

Алгоритмы очередности начинают работать только в моменты переполнения и отключаются после того, как переполнение исчезает. Буфера очередей имеют ограниченную емкость и похожи на воронки с широким входом и узким выходом. Если вы будете постоянно наливать в воронку больше воды, чем из нее вытекает, воронка переполнится. Когда переполняется буфер очереди, входящие пакеты начинают отбрасываться либо в общем порядке (tail-drop), либо избирательно. Избирательное отбрасывание пакетов до полного заполнения буфера называется технологией предотвращения переполнения (congestion avoidance).

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

Инструменты планировки включают в себя:

  • Class-Based Weighted Fair Queuing (CBWFQ, справедливое, взвешенное управление очередями на основе классов). CBWFQ – это композитный алгоритм взвешенной справедливой очередности, позволяющий определять классы по настраиваемым критериям, таким как списки доступа (ACL), входящий интерфейс, протокол и так далее. В рамках Cisco MQC (Modular QoS Command-Line Interface), он позволяет выделять полосу каждой из до 64 очередей и обрабатывать эти очереди по алгоритму справедливой очередности. Он, также, поддерживает механизм WRED (Weighted Random Early Detect – взвешенное случайное раннее обнаружение), в качестве механизма, обеспечивающего свою политику отбрасывания пакетов для каждого класса трафика.
  • Modified Deficit Round Robin (MDRR)—MDRR – это композитный механизм, основанный на использовании классов трафика, и позволяющий организовать буферизацию до восьми классов на платформах Cisco 12000 Series. Он работает подобно CBWFQ и также позволяет организовывать буферизацию трафика чувствительного к задержкам в случае использования очереди строгого приоритета. MDRR может применяться на направлении к матрице коммутации (на входящем интерфейсе) или от матрицы (на исходящем интерфейсе). Биты MPLS EXP и IPP обрабатываются в MDRR одинаково.
  • Low-Latency Queuing (LLQ)—LLQs (использование очереди строгого приоритета в случае MDRR) использует выделенную очередь для обработки трафика чувствительного к задержке, такого как голос или видео. Так как LLQ в MQC включает функцию полисинга трафика, она позволяет обрабатывать пакеты в определенной очереди LLQ в момент поступления, что, в свою очередь, позволяет конфигурировать несколько очередей строгого приоритета (например, одна LLQ очередь может быть сконфигурирована для голоса, а вторая для интерактивного видео). Программное обеспечение абстрагируется от того факта, что на самом деле существует только одна  LLQ очередь. Продолжая пример, если для приоритетной очереди сконфигурировано 100kbps для голосового трафика и 400kbps для интерактивного видео, то программное обеспечение настроит приоритетную очередь на 500kbps.  Оно будет обрабатывать голосовой трафик как трафик строгой приоритетности до 100kbps. Затем, любой дополнительный голосовой трафик будет подвержен полисингу (сброшен), что подчеркивает важность правильной настройки CAC (Call Admission Control). Алгоритм будет продолжать выделять для интерактивного видео 400kbps полосы пропускания. Если поступит более 400kbps видео трафика, то избыточный трафик будет опять же подвержен полисингу. При алгоритме MDRR со строгой приоритетностью приоритетная очередь будет обрабатываться до тех пор, пока в этой очереди есть пакеты. Помимо подобной реализации в MDRR существует буферизация с альтернативной приоритезацией. В этом режиме приоритетная очередь обслуживается по очереди с другими очередями.
  • WRED —WRED – это механизм предупреждения перегрузок в сети, позволяющий осуществить интеллектуальный сброс пакетов на основании маркировки конкретного пакета в момент возникновения перегрузки. Не смотря на то, что сбросы осуществляются и случайным образом, статистически, пакеты с меньшим приоритетом сбрасываются более агрессивно при достижении административно заданного порога заполнения очереди. WRED позволяет избежать проблем с массовым сбросом пакетов в хвосте очереди и глобальной синхронизацией TCP.

Канальные механизмы

Категория канальных механизмов включает:
Средства ограничения скорости (Policing) и выравнивания трафика (Shaping)

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

(Link Fragmentation and Interleaving)—В случае применения низкоскоростных каналов для передачи больших пакетов в канал требуется значительно время. Эту задержку называют задержкой сериализации и она может привести к тому, что для голосовых пакетов будет превышено значение порога задержки и/или колебаний задержки (jitter). Существует два основных инструмента сокращения задержки на низкоскоростных каналах: фрагментация и чередование пакетов для многоканального PPP (Link-Fragmentation and Interleaving for Multilink Point-to-Point Protocol) и Frame Relay фрагментация (FRF.12).
Механизмы компрессии

—Технологии компрессии, такие как Compressed Real-Time Protocol (cRTP), минимизируют требования по полосе пропускания и чрезвычайно эффективны на низкоскоростных каналах. Заголовок IP пакета в 40 байт может составить практически две трети всего пакета. Для того, чтобы избежать неэффективного использования доступной полосы пропускания канала применяется механизм cRTP (он работает не глобально, а на отдельном канале – точка-точка). Применение cRTP позволяет сократить IP/UDP/RTP заголовок с 40 до 2-5 байт.
Настройка буфера TX Ring—Тransmit (TX) ring

– это последняя FIFO очередь, в которой находятся фреймы перед их отправкой на физический интерфейс. Цель этого буфера в том, чтобы гарантировать наличие готового к передаче фрейма на тот момент, когда интерфейс будет готов принять трафик и, таким образом, добиться 100 процентной утилизации канала. Размер TX Ring буфера зависит от модели маршрутизатора, программного обеспечения, среды второго уровня и механизма буферизации сконфигурированного на интерфейсе. Существует рекомендация устанавливать размер TX Ring буфера в значение 3 на низкоскоростных интерфейсах.

Требования к качеству обслуживания корпоративных пользователей и “Базовые Основы QoS”

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

Сводная таблица промежуточного варианта “Базовых Основ QoS” по маркировке трафика представлена в таблице.

Приложение Классификация L3 КлассификацияL2 CoS/MPLS-exp
IPP PHP DSCP
Маршрутная информация 6 CS6 48 6
Голос 5 EF 46 5
Интерактивное видео 4 AF41 34 4
Потоковое видео 4 CS4 32 4
Данные чувствительные к потерям 3 — 25 3
Сигнализация звонков 3 AF31/CS3 26/24 3
Транзакционные данные 2 AF21 18 2
Сетевое управление 2 CS2 16 2
Объемный класс 1 AF11 10 1
Интернет/Scavenger 1 CS1 8 1
Все остальное 0 0 0 0

Примечание №1: В “Базовых Основах QoS” рекомендуется маркировать голосовую сигнализацию с помощью CS3. Однако в настоящий момент, Cisco IP телефоны маркируют сигнализацию как AF31. Миграция от AF31 к CS3 уже запланирована, но как временное решение рекомендуется зарезервировать AF31 и CS3 для сигнализации и использовать DSCP 25 для локальных критичных приложений данных. По завершении миграции следует применять рекомендации “Базовых Основ QoS” по маркировке сигнализации с помощью CS3 и локальных критичных приложений с помощью AF31. Эти рекомендации по маркировке более соответствуют RFC2597 и RFC2474.

Примечание №2: Вторая версия AutoQoS будет автоматически конфигурировать QoS для голоса, видео и данных. Cisco AutoQoS Enterprise будет определять и конфигурировать до 10 классов трафика на основании модели отображенной выше. (Единственный класс, который не будет конфигурироваться автоматически – это локальные критичные данные, так как этот класс требует осведомленности о бизнес процессах, что находится за пределами возможностей AutoQoS). AutoQoS Enterprise предназначен для автоматизации и упрощения проектирования сети в соответствии с “Базовыми Основами QoS”. Хотя AutoQoS и не имеет отношения к операторской сети, для оператора важно понимать его влияние на корпоративные сети. По мере распространения AutoQoS в корпоративных сетях все большее значение будет получать поддержка QoS в операторских сетях.

Требования к качеству обслуживания для голоса

Определяя требования QoS корпоративного VoIP трафика рекомендуется придерживаться следующих правил:

  1. Голосовой трафик должен быть промаркирован как DSCP EF, в соответствии с “Базовыми Основами QoS” и RFC 3246.
  2. Сигнализация должна быть промаркирована как CS3, в соответствии с “Базовыми Основами QoS” (во время миграции можно использовать AF31).
  3. Потери пакетов в магистралях спроектированных для предоставления VoIP сервиса высокого качества не должны превышать 0.25 процентов.
  4. Односторонняя задержка не должна превышать 150ms, в соответствии со International Telecommunication Union (ITU) G.114.
  5. Колебания задержки (jitter) должны быть менее 10 мсек. Максимальный jitter должен быть менее чем бюджет по задержке в сети минус минимальная сетевая задержка. Это типовое значение колебания задержки для VoIP обусловлено бюджетом по задержке, так называемым mouth-to-ear, в 100 мсек. (Это достаточно консервативный бюджет по сравнению с G.114, в котором рекомендуется jitter менее 150 мсек). Из этого значения мы вычитаем время распространения по магистрали (30 мсек) и задержку кодека (35 мсек), что дает нам бюджет для jitter в 35 мсек. Эти 35 мсек разбиваются на 30 мсек на доступе (15 мсек вход/выход) и 5 мсек на магистрали. То есть в худшем варианте, для адаптивных jitter-буферов, колебания задержки должны быть менее 10 мсек.
  6. Для каждого разговора (в зависимости от частоты квантирования, кодека и заголовка второго уровня) требуется 21-106 kbps гарантированной приоритетной полосы пропускания.
  7. Для трафика сигнализации требуется 150 bps (плюс заголовок второго уровня) гарантированной полосы пропускания.

На качество голосовой связи напрямую влияют все три фактора качества QoS: потери пакетов, задержка и вариации задержки.

  1. Потери пакетов вызывают кратковременные пробелы в разговоре. Стандартные алгоритмы кодирования используемые в Cisco Digital Signal Processor (DSP) с помощью алгоритмов маскирования могут восстановить потери до 30 мсек. Таким образом, потери двух и более последовательных 20 мсек сэмплов приведут к заметной деградации качества голоса. Предположив случайное распределение сбросов пакетов в одном речевом потоке, сброс 1-го процента в голосовом потоке привела бы в среднем к потери, которую нельзя было бы восстановить каждые 3 минуты. Аналогично, уровень сброса 0,25 процента привел бы в среднем к потери, которую нельзя было бы восстановить каждые 53 минуты.
  2. Задержка более 200 мсек может вызвать деградацию качества голосовой связи. Если общая задержка в канале становится слишком большой, разговор по телефону начинает напоминать переговоры по спутниковому каналу связи или по симплексному радиоканалу. В стандарте Международного Союза Электросвязи для технологии VoIP (G.114) говорится, что задержка величиной в 150 мсек в одном направлении является приемлемой для качество голосовой связи. Было продемонстрировано, что разница в качестве голоса между сетями с задержкой в 150 мсек и 200 мсек является незначительной и практически незаметной для пользователя. Cisco рекомендует ориентироваться на ITU стандарт 150 мсек, но если существуют ограничения не позволяющие добиться такого бюджета, то размер задержки может быть увеличен до 200 мсек без значительной деградации качества связи.
  3. Что же касается колебаний задержки, то для их выравнивания в устройствах Cisco для IP-телефонии используются адаптивные буферы. Однако они могут компенсировать колебания задержки лишь в пределах от 20 до 50 мсек. При централизованной обработке вызовов IP-телефоны используют контрольные каналы TCP для связи с Cisco CallManager. Если эти весьма небольшие каналы не получат достаточной полосы пропускания, качество обслуживания абонентов будет ухудшаться. Давайте для примера рассмотрим время, которое проходит с момента поднятия трубки до момента, когда абонент слышит гудок. Когда абонент поднимает трубку IP-телефона, телефон “спрашивает” CallManager, что делать дальше. CallManager, в свою очередь, говорит IP-телефону, чтобы тот начал воспроизведение гудка в поднятой трубке. Если контрольный трафик будет потерян или задержан в сети, пользователь не услышит гудка и решит, что телефон не работает. Та же логика применима к любому сигнальному трафику, которым обмениваются шлюзы и телефоны.

Выделение полосы пропускания для голоса и видео

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

Операторы должны гарантировать соответствующую полосу пропускания для VoIP приложений корпоративных клиентов. Планирование должно быть достаточно точным и учитывать несколько факторов. Лимитирующим фактором для выделения процента общей полосы пропускания являются параметры задержки и колебаний задержки, а также общей пропускной способности последней мили. Трафик попадающий в приоритетные очереди (LLQ или PQ) подвергается задержке вследствие уровня утилизации канала и задержки сериализации одного VoIP пакета. Максимальный процент VoIP трафика на конкретном канале между оператором и клиентом зависит от:

  • Бюджета задержки на канале доступа;
  • Максимальной задержки на пустой LLQ/PQ очереди. Это должно исключать задержку вызванную конфликтами VoIP пакетов;
  • Скорости подключения. Для данной скорости задержка, вызванная конфликтами VoIP пакетов, будет расти с ростом интервалов пакетизации и последующим ростом задержки сериализации VoIP пакета;
  • Используемого кодека и интервала пакетизации. Для данного кодека и интервала пакетизации, задержка вызванная конфликтами пакетов VoIP будет расти с процентным ростом LLQ/PQ составляющей трафика на линии доступа. Задержка будет падать с ростом полосы пропускания канала. Чем более скоростные кодеки применяются, тем больше будет задержка связанная с ростом размера VoIP пакетов, что, в свою очередь, увеличивает задержку сериализации. Основываясь на выше изложенном, пример планирования VoIP в части процентного соотношения PQ трафика в сети оператора выглядит следующим образом:
  • Скорость доступа к сети 512 kbps и оптимальный бюджет по задержке на канале доступа 15 мсек
  • Худший вариант задержки на не загруженной PQ очереди – 10 мсек;
  • 5мсек-задержки буферизации VoIP
  • G.711 кодек даст 20 мсек без cRTP В этом случае можно гарантировать максимум два вызова, что составляет примерно 35 процентов загрузки PQ очереди. Это дает нам примерно 180 kbps с небольшим запасом. При расчете полосы пропускания для VoIP необходимо обеспечить достаточно дополнительной емкости и для трафика данных.

Требования к качеству обслуживания для Видео

Существует два основных типа видео приложений: Интерактивное видео (например видео конференции) и Потоковое видео (например IP/TV, которое может использовать как одно-так и многоадресную рассылку).

Настройки для трафика интерактивного видео

При настройке интерактивного видео (видео конференций) рекомендуется следующее:

  • Интерактивный видео трафик, в соответствии с “Базовыми основами QoS”, должен быть промаркирован AF41.
  • Потери должны быть не более одного процента.
  • Однонаправленная задержка должна быть не более 150 мсек.
  • Колебания задержки должны быть не более 30 мсек.
  • Минимально гарантированная полоса пропускания (LLQ) должна быть равна размеру сессии видео конференции плюс 20 процентов. (Например, сессия видео конференции в 384 kbps требует настройки 460 kbps полосы трафика гарантированного приоритета.)

Так как видео конференция включает аудио кодек G.711 для речи, то у нее и соответствующие голосовому трафику требования к потерям, задержке и колебаниям задержки. Однако трафик видео конференции радикально отличается от трафика голоса. Например, трафик видео конференций использует переменные размеры пакетов и переменные скорости передачи пакетов. Скорость видео конференции – это скорость сэмплирования видео потока, но не реальная полоса пропускания, которую требует видео вызов. Иными словами, полезная нагрузка пакетов видео конференции заполняется 384 kbps потока видео сэмплов. IP, UDP и RTP заголовки (40 байт на пакет) должны быть дополнительно включены в требования по полосе пропускания (также как и заголовки второго уровня). Так как используются переменные размеры пакетов и скорости генерации пакетов, то достаточно трудно точно подсчитать абсолютное значение накладных расходов. Тестирование, однако, показало, что для расчета можно использовать скорость видео конференции плюс 20 процентов. Замечание: Алгоритм LLQ Cisco по умолчанию поддерживает всплески до 200 мсек трафика. Тестирование показало, что этой настройки достаточно для видео конференций. Для поддержки большего количества потоков можно по потребности увеличить этот параметр.

Настройки для трафика потокового видео

При настройке потокового видео рекомендуется следующее:

  • Потоковое видео (одноадресной или многоадресной рассылки), в соответствии с “Базовыми основами QoS” должно быть промаркировано CS4.
  • Потери должны быть менее 2 процентов.
  • Задержка должна быть менее 4-5 секунд (в зависимости от возможностей буферизации видео приложений).
  • Не существует значительных требований по колебанию задержки.
  • Требования по гарантиям полосы (CBWFQ) зависят от формата кодирования скорости видео потока.
  • Потоковое видео обычно однонаправленное и, поэтому, в удаленных филиалах маршрутизаторы можно не настраивать на поддержку потокового видео в направлении от филиала к центру.
  • Не важные приложения потокового видео, такие как видео для развлечения, могут быть промаркированы DSCP CS1 и для них требуется минимум гарантий полосы пропускания в очереди CBWFQ (Используя класс Интернет/scavenger). Приложения потокового видео менее требовательны к QoS, так как они менее чувствительны к задержкам (может пройти несколько секунд перед началом видео картинки) и нечувствительны к колебаниям задержки (благодаря буферизации на уровне приложений). Однако, потоковое видео может содержать важную информацию, такую как электронное обучение или трансляцию корпоративных совещаний и, следовательно, требовать гарантий QoS. Не важное видео содержание (такое как фильмы, музыкальные видео клипы и так далее) может рассматриваться как Интернет сервис (сервис хуже чем “Best Effort”), что означает, что эти потоки работают пока есть полоса пропускания, но будут вытесняться в случае возникновения перегрузок в сети.

Требования к качеству обслуживания для трафика данных

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

Используйте не более четырех основных классов трафика, такие как

  • Локально-определенный Критический (для критически важных приложений) —транзакционные и интерактивные приложения с высоким бизнес-приоритетом;
  • Транзакционный/интерактивный — приложения клиент-сервис, приложения по передаче сообщений;
  • Объемные приложения— передача больших файлов, синхронизация и репликация баз данных, электронная почта (e-mail);
  • По возможности— класс по умолчанию для всего не назначенного трафика; конфигурируйте как минимум 25 процентов полосы для этого класса;
  • Опционный класс – Интернет/scavenger (игровой трафик, развлечения…) Дополнительный опционный класс включает в себя маршрутизацию и сетевое управление.

Локально-определенный Критический класс трафика данных

Локально-определенный Критический класс трафика данных – это возможно самый недопонимаемый класс трафика в “Базовых основах QoS”. В соответствии с моделью “Базовых основ QoS” все классы трафика (за исключением Интренет/scavenger и Best-Effort) рассматриваются как критические для корпоративного клиента. Термин локально-определенный используется, чтобы подчеркнуть назначение этого класса – то есть иметь высший класс сервиса для каждого клиента для избранного набора их интерактивных и транзакционных приложений, имеющий для них наибольший бизнес-приоритет. Например, компания может настроить Oracle, SAP, BEA и DLSw+, как транзакционный/интерактивный класс. Однако, большая часть их доходов зависит от SAP, и тогда они могут захотеть дать этому транзакционному приложению еще более высокий уровень приоритета, назначив его в выделенный класс (такой как локально-определенный критический класс). Так как критерий назначения такого класса не технический (а определяется бизнес требованиями и целями организации), решение о том, какие приложения должны попасть в этот специальный класс могут быть решены только организационно. В этот класс рекомендуется назначать как можно меньшее количество приложений.
Транзакционный/Интерактивный класс данных

Транзакционный/Интерактивный класс – это комбинация двух схожих типов приложений: транзакционных приложений клиент-сервер и приложений интерактивных сообщений. Требования по времени отклика отличают транзакционные от обычных клиент-серверных приложений. В случает транзакционных клиент-серверных приложений (таких как SAP, PeopleSoft и DLSw+) пользователь вынужден ожидать завершения операции. E-mail – это не транзакционное приложение, так как большинство операций происходит в фоновом режиме и пользователи, обычно, не замечают задержек в несколько сот миллисекунд. Замечание: по умолчанию, DLSw+ помечает свой IP трафик IPP 5, что конфликтует с VoIP. Таким образом, рекомендуется перемаркировать трафик DLSw+.
Объемный класс данных (Bulk)

Класс данных Объемный предназначен для не интерактивных приложений не критичных к потерям пакетов, обычно работающих в фоновом режиме. Такие приложения включают: FTP, e-mail, backup, синхронизация и репликация баз данных, распространение видео содержания или другие типы приложений, в которых пользователь не вынужден ждать результатов выполнения операций. Преимущество выделения полосы пропускания для Объемного класса трафика (вместо накладывания на них ограничений) заключается в том, что приложения могут динамически использовать свободную полосу пропускания и, таким образом, повышать свою производительность в спокойные периоды времени, что, в свою очередь, снижает вероятность влияния на них перегрузок.
Класс По возможности (Best Effort)

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

Интернет/Scavenger Класс предназначен для предоставления определенным приложениям дифференцированных услуг или услуг по остаточному принципу. Эти приложения, как правило, не имеют прямого отношения к основному бизнесу компании и обычно ориентированы на развлечение. Они включают: приложения однорангового медиа-обмена (KaZaa, Morpheus, Groekster, Napster, iMesh, и т.д.), игровые приложения (Doom, Quake, Unreal Tournament, и т.д.), и развлекательные видео приложения. Это типичный класс определенный для корпоративного клиента, но обычно перемаркируемый на класс Best Effort на границе сети оператора. Назначение минимальных гарантий по полосе пропускания этому классу означает, что в моменты перегрузок он практически не получает никаких ресурсов, но может использовать свободную полосу в спокойные периоды.
Классы Маршрутизации и Сетевого управления

Некоторые клиенты предпочитают в явном виде гарантировать минимальную полосу пропускания для протоколов маршрутизации и приложений сетевого управления (SNMP, NTP, Syslog или NFS). Замечание: Важно отметить, что протоколы внутренней маршрутизации, такие как RIP и EIGRP, обычно не требуют выделения специальной полосы пропускания. Это преимущество использования внутреннего механизма Cisco — PAK_PRIORITY. В OSPF только пакеты hello маркируются с помощью PAK_PRIORITY. В BGP (хотя он и раскрашен IPP6/CS6) также могут потребоваться специальные настройки. Информация по PAK_PRIORITY.

Влияние полно-связности сетей MPLS VPN на QoS

Из-за дороговизны, недостатков масштабируемости и ограниченной управляемости полно-связные топологии редко встречаются в традиционных дизайнах. Напротив, большинство дизайнов второго уровня построены по принципу hub-and-spoke используя либо централизованный хаб или более эффективный дизайн с региональными хабами. При таком дизайне QoS обычно настраивается и администрируется клиентом на центральном узле. До тех пор пока оператор обеспечивает контрактный уровень обслуживания, фреймы или ячейки на удаленных узлах соответствуют политике центрального узла (иногда называемого WAN агрегатором). WAN агрегатор контролирует не трафик только в направлении от центра к филиалу, но и от филиала к филиалу, как показано на рисунке №1.

Рисунок №1. Администрирование QoS при традиционном Hub-and-Spoke WAN дизайне (контролируется клиентом).

Однако, с внедрением услуги MPLS VPN, которая по природе своей предлагает полную связность, решение по обеспечению QoS видоизменяется. При полно-связном дизайне центральный маршрутизатор продолжает администрировать QoS для всего трафика от центра к филиалам, но более не контролирует QoS для трафика от филиала к филиалу. Может показаться, что единственное изменение касается настройки QoS на всех филиальных маршрутизаторах, но это не так, так как решает только часть задачи. Например, рассмотрим пример настройки видео конференции каждый с каждым. Как и в случае традиционного дизайна второго уровня требуется настройка на WAN агрегаторе политики приоритезации IP/VC трафика. Затем клиент должен соответствующим образом настроить и филиальные маршрутизаторы. Таким образом, любые видео вызовы из центра в филиалы и между филиалами защищены по отношению к менее важному трафику между теми же точками. Сложность полно-связной модели появляется в случае принятия во внимание того факта, что конкурирующий трафик может теперь не всегда приходить с того же сайта, а может приходить c любого. Более того, теперь клиент не контролирует QoS трафика между филиалами, так как теперь он не проходит через центральный хаб. Продолжая пример, если видео конференция работает между двумя филиалами и пользователь одного из филиалов начинает большую FTP загрузку файла с центрального узла, то появляется потенциальная возможность возникновения перегрузки PE-CE канала со стороны облака полно-связной MPLS VPN. Это может привести к ухудшению качества видео конференции. Единственное решение в этом сценарии – это необходимость для оператора сконфигурировать QoS на всех РЕ, к которым подключены филиалы, в соответствии с политикой клиента. Иными словами, операторы и их клиенты должны согласовывать политику QoS в MPLS VPN, как это показано на рисунке №2.

Рисунок №2. Администрирование QoS в полно-связном MPLS VPN дизайне (QoS администрируется совместно оператором и клиентом).

Руководство по сокращению классов обслуживания в корпоративных сетях

Несмотря на принятие Cisco инициативы “Базовых основ QoS” и наличие инструментов типа Cisco AutoQoS Enterprise для упрощения и ускорения внедрения комплексных моделей QoS в корпоративных сетях, на сегодняшний момент не многие компании используют большое количество классов трафика. Поэтому большинство операторов предлагают ограниченное количество классов при предоставлении услуги MPLS VPN. Со временем, это может привести к необходимости сокращения в корпоративных сетях количества поддерживаемых классов для интеграции с моделями QoS операторов. Вопросы, рассматриваемые в этом разделе, должны быть учтены в процессе выбора стратегии по сокращению числа классов и интеграции классов клиента с классами поддерживаемыми в сети оператора.

Вопросы сериализации

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

Обычно, операторы предлагают только один класс сервиса “реального времени” или “приоритетный” класс. Если заказчик хочет использовать в своей MPLS VPN и голос и интерактивное видео (каждый из которых рекомендуется назначать в класс строгой приоритетности), то перед ним может встать проблема выбора. Какой трафик должен быть назначен в класс “реального времени”? Существуют ли какие либо последствия назначения обоих типов трафика в один класс “реального времени”? Голос и Видео никогда не должны быть назначены в одну и ту же очередь низкой задержки на каналах, скорость которых менее 768kbps, то есть где присутствует фактов сериализации. Пакеты в LLQ очереди обычно не фрагментируются и, таким образом, большие пакеты IP/VC могут привести к значительным задержкам VoIP пакетов. Альтернативным решением может быть назначение IP/VC в менее приоритетный класс, что приведет не только к очевидной деградации качества (более низкий уровень сервиса), но также может быть подвержено влиянию смешивания разнородного трафика. Это описано в разделе “Смешивание TCP и UDP”.
Сигнализация голосовых вызовов

VoIP требует конфигурирования не только трафика RTP полезной нагрузки, но также и сигнального или трафика управления вызовами. Этот трафик незначителен и требует малую гарантированную полосу пропускания. Так как уровень сервиса, c которым работает телефонная сигнализация, определяет время задержки выдачи в телефонную трубку тона приглашения к набору, то этот уровень становится важен с точки зрения ожиданий конечного абонента. Операторы не всегда могут предоставить подходящий класс сервиса только для трафика сигнализации, что приводит к вопросу – с какими другими классами трафика можно смешивать трафик сигнализации? На каналах где не значителен эффект сериализации (то есть более 768kbps), сигнализация может быть отнесена к классу реального времени, вместе с голосом. Этого не рекомендуется делать на более низкоскоростных каналах. Вместо этого, сигнализация должна быть назначена в один из приоритетных классов данных, для которых оператор дает гарантии по полосе пропускания. Важно понимать, что гарантии оператора на определенный класс, не означают гарантий по полосе пропускания для конкретного приложения.

Смешение TCP и UDP

Рекомендуется не смешивать TCP трафик и трафик UDP (особенно потоковое видео) в одном и том же операторском классе из-за различного поведения этих протоколов в моменты возникновения перегрузок. В частности, TCP начнет тормозить потоки в том случае, если будут обнаружены потери пакетов. Не смотря на то, что некоторые UDP приложения используют окна, управление потоком и возможности перепосылки, в большинстве своем, UDP передатчики нечувствительны к потерям пакетов и не снижают скорость передачи. В случае объединения TCP и UDP потоков в одном классе, и в случае если в этом классе возникает перегрузка, то TCP потоки начнут последовательно снижать скорость, потенциально отдавая свою полосу пропускания UDP потокам, нечувствительным к потерям. Этот эффект называется TCP-starvation/UDP-dominance (Доминация UDP/Истощение TCP)

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

Рекомендации по маркировке

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

Общее правило маркировки в корпоративных сетях заключается в маркировке трафика и установке границ доверия как можно ближе к источнику, насколько это возможно административно и технически. IP телефоны, например, маркируют голосовой трафик DSCP EF (46), и существующие руководства по дизайн рекомендуют доверять этой маркировке. Однако рекомендуется не доверять маркировке установленной на хостах пользователей (так как здесь возможны злоупотребления). Определенные типы трафика, возможно, нужно перемаркировать еще до передачи на пограничные устройства оператора для получения доступа к определенному классу. Если требуется такая перемаркировка, то рекомендуется производить ее на исходящем CE маршрутизаторе, а не в кампусной сети. Это связано с тем, что набор предлагаемых оператором сервисов скорее всего изменится или расширится со временем, а производить перенастройку проще, если она производится только на CE границе. Могут существовать классы, где множество типов трафика требуется пометить одинаковыми значениями для получения доступа к определенным очередям. Например, на высокоскоростных каналах может потребоваться передавать голос, интерактивное видео и сигнализацию в операторском классе реального времени. Если в операторский класс реального времени направляются только пакеты промаркированные DSCP EF и CS5, то это означает, что три этих приложения должны использовать один и тот же код приоритета DSCP. Пример конфигурации далее демонстрирует, как это может быть сделано с помощью маркирования классов (в этом примере и интерактивное видео и сигнализация используют DSCP CS5).

class-map match-any VOICE
 match ip dscp ef
class-map match-all INTERACTIVE-VIDEO 
 match ip dscp af41
class-map match-any CALL-SIGNALING
 match ip dscp af31
 match ip dscp cs3
policy-map CE-EGRESS-EDGE
 class VOICE
  priority percent 18
 class INTERACTIVE-VIDEO
  priority percent 15
  set ip dscp cs5
 class CALL-SIGNALING
  priority percent 2
  set ip dscp cs5
interface Serial1/0
 service-policy output CE-EGRESS-EDGE

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

Операторы могут перемаркировать трафик на третьем уровне для отображения того факта, что определенные потоки поступили с превышением контрактных обязательств. Это делается в соответствии со стандартами DiffServ, в частности RFC 2597. Однако некоторым клиентам, для целей управления и сбора статистики, требуется последовательная сквозная маркировка. В таких случаях клиенту может потребоваться перемаркировка трафика полученного из операторской сети (во входящем направлении на клиентском СЕ маршрутизаторе). В этом случае может использоваться маркировка по классам (class-based marking), так как она поддерживает списки доступа для классификации пакетов, а также NBAR (распознавание на уровне приложений). Продолжая и расширяя предыдущий пример, клиент захотел восстановить первоначальное значение маркировки для интерактивного видео и голосовой сигнализации. Дополнительно они хотят восстановить первоначальную маркировку для трафика Oracle (который они изначально пометили DSCP 25 используя TCP Port 9000) и трафика DLSw+ (изначально помеченный AF21). Трафик этих приложений они передали в сеть оператора с маркировкой AF21, но возможно в операторской сети он был перемаркирован в AF22. Фрагмент такой конфигурации показан ниже. Используемый критерий “match-all” в карте класса (class-map) выполняет операцию логического “И” между потенциальными маркировками и перемаркировками и списком доступа (или протоколом поддерживаемым NBAR). Политика применяется к тому же СЕ-РЕ интерфейсу, только во входящем направлении.

class-map match-all REMARKED-INTERACTIVE-VIDEO
 match ip dscp cs5
 match access-group 101
class-map match-all REMARKED-CALL-SIGNALING
 match ip dscp cs5
 match access-group 102
class-map match-all REMARKED-ORACLE
 match ip dscp af21 af22
 match access-group 103
class-map match-all REMARKED-DLSW+
 match ip dscp af21 af22
 match protocol dlsw
policy-map CE-INGRESS-EDGE
 class REMARKED-INTERACTIVE-VIDEO
  set ip dscp af41
 class REMARKED-CALL-SIGNALING
  set ip dscp af31
 class REMARKED-ORACLE
  set ip dscp 25
 class REMARKED-DLSW+
  set ip dscp af21
interface serial 1/0
 service-policy output CE-EGRESS-EDGE
 service-policy input CE-INGRESS-EDGE
access-list 101 permit udp any any
access-list 102 permit tcp any any
access-list 103 permit tcp any eq 9000 any

Прозрачность QoS с использованием Методов Туннелирования MPLS DiffServ (QoS Transparency with MPLS DiffServ Tunneling Modes)

Во многих случаях оператору желательно проводить собственную политику QoS и выдерживать Соглашения о качестве обслуживания (SLA) не изменяя значений DSCP и IPP клиента. Для туннелирования QoS маркировки пакетов и обеспечения прозрачности QoS клиента может использоваться MPLS. Например можно выставлять значения поля MPLS EXP отличными (и даже независимо) от значений полей IPP или DSCP. Для назначения пакетов в тот или иной класс PHB (класс поведения на узле коммутации) с последующим установкой поля MPLS EXP при назначении пакету MPLS метки оператор может пользоваться различными критериями классификации -включая или исключая маркировку IP РНВ. Например, это может быть полезно оператору, которому требуется выполнение SLA для трафика клиента, но без привязки к используемой этим заказчиком политики маркировки QoS и без переписывания значений IP PHB клиента. Это можно рассматривать как инкапсуляцию РНВ клиентского пакета в туннельный РНВ оператора. Существует три метода туннелирования MPLS DiffServ (описанные в RFC 3270). Это:

  • Унифицированный метод (Uniform Mode);
  • Метод Короткой Трубы (Short Pipe Mode);
  • Метод Трубы (Pipe Mode).

Унифицированный метод (Uniform Mode)

Унифицированный метод используется в том случае, когда и клиент и оператор используют один и тот же домен DiffServ (иными словами используют одинаковую политику маркировки трафика). Внешний заголовок всегда используется для определения QoS РНВ. При назначении MPLS метки в поле MPLS EXP копируется значение классификации IPP. Это происходит по умолчанию. Для обеспечения полной поддержки DSCP на входящем интерфейсе, где устанавливается определенное значение приоритетности сброса пакетов для каждого заказчика, можно использовать команду set mpls exp imposition (в описании input policy map). На выходе из операторской сети, в процессе снятия внешней метки, маршрутизатор переносит значение CoS в поле IP DSCP. Этот процесс конфигурируется командой mpls propagate-cos на исходящем РЕ. Для полной поддержки DSCP в Унифицированном режиме в процессе снятия метки следует использовать комбинацию qos-groups и discard-classes в описании входящей карты политик на исходящем РЕ маршрутизаторе. Это обеспечивает соответствующую обработку пакета в процессе коммутации и в исходящей очереди уже после того как была снята метка, как показано на рисунке №3.


Рисунок №3. Унифицированный метод (Uniform Mode).

Метод Короткой Трубы (Short Pipe Mode)

Метод Short Pipe применяется в том случае, когда клиент и оператор используют различные домены DiffServ. Это полезно в тех случаях, когда оператор использует собственную политику DiffServ и требованием клиента является сохранение его DiffServ информации, то есть сеть оператора обеспечивает прозрачность DiffServ настроек клиента. Внешняя метка определяет QoS PHB оператора. В процессе назначения метки не происходит копирования IP классификации в поле EXP MPLS пакета. Значение MPLS EXP устанавливается с помощью команды set mpls exp imposition на входящем РЕ маршрутизаторе. Таким образом помечается CoS на внешней метке пакета, но само содержимое заголовка (IP DSCP) остается прежним. Для пере-классификации пакетов в туннеле необходимо использовать команду set mpls experimental topmost при определении политики либо на входящем либо на исходящем интерфейсе, там где требуется пере-классификация. На выходе из операторской сети, в процессе снятия внешней метки, РЕ маршрутизатор не трогает значение DSCP информации в заголовке пакета клиента, как это показано на рисунке №4

Рисунок №4. Метод Short Pipe

Метод Трубы (Pipe Mode)

Метод Pipe очень похож на метод Short Pipe, так как клиент и оператор используют различные домены DiffServ. Отличие заключается в том, что при методе Pipe оператор использует значение собственной классификации для конфигурирования алгоритмов обработки очередей WRED, WFQ (и не использует для этих целей маркировку пакетов клиента). Это влияет на процесс обработки пакета на исходящем РЕ до снятия внешней метки. Для этих целей в картах политик на исходящем РЕ используются параметры qos-group и discard-class. Такая конфигурация избавляет от необходимости настроек исходящих интерфейсов РЕ для каждого клиента с индивидуальными правилами обработки классов для каждого клиента. Метод Pipe проиллюстрирован на рисунке №5.

Рисунок №5. Метод Pipe

Модели мапирования классов Клиент-Оператор

Операторы могут предложить клиентам MPLS VPN множество моделей QoS. На скоростях E1 и ниже маловероятно, что клиенту предложат более 3-5 моделей, поэтому возможно мапирование 1:1. На более скоростных интерфейсах возможно потребуется мапирование в меньшее количество операторских классов. Несколько примеров такого мапирования проиллюстрированы ниже.

Операторская Модель Трех Классов

В этой модели оператор предлагает три класса сервиса: реального времени (строгая приоритетность), критические данные (гарантированная полоса) и best effort (по возможности). Признаком классификации в класс реального времени служит DSCP EF или CS5; класс критических данных DSCP CS 6, AF31 или CS3. Все остальные значения перемаркируются в 0. Дополнительно, трафик AF31 поступивший с превышением контракта перемаркируется в AF32. В такой модели не рекомендуется использовать потоковое видео (раздел “Смешение TCP и UDP”). Аналогично, в этой модели нет операторского класса подходящего для передачи Объемных данных (Bulk Data), которые представляют собой большие, не динамичные TCP сессий, которые могли бы вытеснить более мелкие транзакции данных. Диаграмма перемаркировки (Рисунок №6) и соответствующий фрагмент конфигурация представлены ниже. В этом примере используется двойной канал T1.

Рисунок №6. Диаграмма перемаркировки для модели трех классов.

Операторская Модель Трех Классов: Конфигурация CE

Пример конфигурации СЕ клиента для мапирования в Операторскую Модель Трех Классов представлена ниже.

class-map match-all ROUTING
 match ip dscp cs6
class-map match-all VOICE
 match ip dscp ef
class-map match-all INTERACTIVE-VIDEO
 match ip dscp af41
class-map match-all MISSION-CRITICAL-DATA
 match ip dscp 25
class-map match-any CALL-SIGNALING
 match ip dscp af31
 match ip dscp cs3
class-map match-all TRANSACTIONAL-DATA
 match ip dscp af21
class-map match-all NETWORK-MANAGEMENT
 match ip dscp cs2
class-map match-all SCAVENGER
 match ip dscp cs1
policy-map CE-THREE-CLASS-SP-MODEL
 class ROUTING
  bandwidth percent 3
 class VOICE
  priority percent 18
 class INTERACTIVE-VIDEO
  priority percent 15
  set ip dscp cs5
 class CALL-SIGNALING
  priority percent 2
  set ip dscp cs5
 class MISSION-CRITICAL-DATA
  bandwidth percent 20
  random-detect
  set ip dscp af31
 class TRANSACTIONAL-DATA
  bandwidth percent 15
  random-detect
  set ip dscp cs3
 class NETWORK-MANAGEMENT
  bandwidth percent 2
  set ip dscp cs3
 class SCAVENGER
  bandwidth percent 1
 class class-default
  bandwidth percent 24
  random-detect
interface serial 1/0
 max-reserved bandwidth 100
 service-policy output CE-THREE-CLASS-SP-MODEL

WRED (а по сути RED, так как значения IPP у всех классов одинаковы) включен только на основных классах данных. Тестирование показало очень незначительное улучшение производительности при включении WRED также и на специализированных классах (таких как протоколы маршрутизации, сетевое управление и голосовая сигнализация). Более того, если классы маршрутизации и голосовой сигнализации будут подвержены сбросам, то скорее всего потребуется конфигурирование дополнительной полосы пропускания. Этот пример также гарантирует минимальную полосу пропускания для класса по умолчанию (24 процента). Если не использовать команду bandwidth в классе по умолчанию, то в случае появления дополнительного трафика классов Объемный (Bulk) или Интернет (Scavanger) пострадает класс По умолчанию. Однако теперь сумма полос пропускания всех сконфигурированных классов превышает 75 процентов, поэтому прежде чем транслятор примет настройки “service policy”требуется интерфейсная команда max reserved bandwidth 100.

Операторская Модель Трех Классов: Конфигурация РE

Пример конфигурации РЕ оператора для мапирования в Операторскую Модель Трех Классов представлена ниже.

class-map match-any REALTIME
 match ip dscp ef
 match ip dscp cs5
class-map match-any CRITICAL-DATA
 match ip dscp cs6
 match ip dscp af31
 match ip dscp cs3
policy-map PE-THREE-CLASS-SP-MODEL
 class REALTIME
  priority percent 35
 class CRITICAL-DATA
  bandwidth percent 40
  random-detect dscp-based
 class class-default
  fair-queue
  random-detect

Операторская Модель Четырех Классов

Основываясь на предыдущей модели мы добавляем четвертый класс, который может использоваться для Объемных данных (Bulk Data) или потокового видео. Признаком классификации в этот новый класс служит DSCP AF21 или CS2. Ниже приведен пример использования этого нового класса для передачи потокового видео и (в основном UDP) трафика сетевого управления.

Рисунок №7. Диаграмма перемаркировки Операторской Модели Четырех Классов

Операторская Модель Четырех Классов: Конфигурация CE

Пример конфигурации СЕ клиента для мапирования в Операторскую Модель Четырех Классов представлена ниже.

class-map match-all ROUTING
 match ip dscp cs6
class-map match-all VOICE
 match ip dscp ef
class-map match-all INTERACTIVE-VIDEO
 match ip dscp af41
class-map match-all STREAMING-VIDEO
 match ip dscp cs4
class-map match-all MISSION-CRITICAL-DATA
 match ip dscp 25
class-map match-any CALL-SIGNALING
 match ip dscp af31
 match ip dscp cs3
class-map match-all TRANSACTIONAL-DATA
 match ip dscp af21
class-map match-all NETWORK-MANAGEMENT
 match ip dscp cs2
class-map match-all SCAVENGER
 match ip dscp cs1
policy-map CE-FOUR-CLASS-SP-MODEL
 class ROUTING
  bandwidth percent 3
 class VOICE
  priority percent 18
 class INTERACTIVE-VIDEO
  priority percent 15
  set ip dscp cs5
 class STREAMING-VIDEO
  bandwidth percent 13
  set ip dscp af21
 class CALL-SIGNALING
  priority percent 2
  set ip dscp cs5
 class MISSION-CRITICAL-DATA
  bandwidth percent 12
  random-detect
  set ip dscp af31
 class TRANSACTIONAL-DATA
  bandwidth percent 10
  random-detect
  set ip dscp cs3
 class NETWORK-MANAGEMENT
  bandwidth percent 2
 class SCAVENGER
  bandwidth percent 1
 class class-default
  bandwidth percent 24
  random-detect
interface serial 1/0
 max-reserved bandwidth 100
 service-policy output CE-FOUR-CLASS-SP-MODEL

Операторская Модель Четырех Классов: Конфигурация РE

Пример конфигурации РЕ оператора для мапирования в Операторскую Модель Четырех Классов представлена ниже.

class-map match-any REALTIME
 match ip dscp ef
 match ip dscp cs5
class-map match-any CRITICAL-DATA
 match ip dscp cs6
 match ip dscp af31
 match ip dscp cs3
class-map match-any PREFERRED-DATA
 match ip dscp af21
 match ip dscp cs2
policy-map PE-FOUR-CLASS-SP-MODEL
 class REALTIME
  priority percent 35
 class CRITICAL-DATA
  bandwidth percent 25
  random-detect dscp-based
 class PREFERRED-DATA
  bandwidth percent 15
  random-detect dscp-based
 class class-default
  fair-queue
  random-detect

Операторская Модель Пяти Классов

Опять же основываясь на предыдущей модели мы добавляем пятый класс, который можно использовать для передачи Объемных Данных (Bulk Data) или потокового видео (то что не использовалось в модели четырех классов). Признаком классификации в этот новый класс служит DSCP AF11 или CS1, что влечет за собой ранее не требуемое перемаркирование Интернет/Scavanger класса в DSCP 0 (так, чтобы он не попал в класс Объемных данных (Bulk Data), а попал в класс По умолчанию.

Рисунок №8. Диаграмма перемаркировки Операторской Модели Пяти Классов

Операторская Модель Пяти Классов: Конфигурация CE

Пример конфигурации СЕ клиента для мапирования в Операторскую Модель Пяти Классов представлена ниже.

class-map match-all ROUTING
 match ip dscp cs6
class-map match-all VOICE
 match ip dscp ef
class-map match-all INTERACTIVE-VIDEO
 match ip dscp af41
class-map match-all STREAMING-VIDEO
 match ip dscp cs4
class-map match-all MISSION-CRITICAL-DATA
 match ip dscp 25
class-map match-any CALL-SIGNALING
 match ip dscp af31
 match ip dscp cs3
class-map match-all TRANSACTIONAL-DATA
 match ip dscp af21
class-map match-all BULK-DATA
 match ip dscp af11
class-map match-all NETWORK-MANAGEMENT
 match ip dscp cs2
class-map match-all SCAVENGER
 match ip dscp cs1
policy-map CE-FIVE-CLASS-SP-MODEL
 class ROUTING
  bandwidth percent 3
 class VOICE
  priority percent 18
 class INTERACTIVE-VIDEO
  priority percent 15
  set ip dscp cs5
 class STREAMING-VIDEO
  bandwidth percent 13
  set ip dscp af21
 class CALL-SIGNALING
  priority percent 2
  set ip dscp cs5
 class MISSION-CRITICAL-DATA
  bandwidth percent 12
  random-detect
  set ip dscp af31
 class TRANSACTIONAL-DATA
  bandwidth percent 5
  random-detect
  set ip dscp cs3
 class NETWORK-MANAGEMENT
  bandwidth percent 2
 class BULK-DATA
  bandwidth percent 5
  random-detect
 class SCAVENGER
  bandwidth percent 1
  set ip dscp 0
 class class-default
  bandwidth percent 24
  random-detect
interface serial 1/0
 max-reserved bandwidth 100
 service-policy output CE-FIVE-CLASS-SP-MODEL

Операторская Модель Пяти Классов: Конфигурация РE

Пример конфигурации РЕ оператора для мапирования в Операторскую Модель Пяти Классов представлена ниже.

class-map match-any REALTIME
 match ip dscp ef
 match ip dscp cs5
class-map match-any CRITICAL-DATA
 match ip dscp cs6
 match ip dscp af31
 match ip dscp cs3
class-map match-any PREFERRED-DATA
 match ip dscp af21
 match ip dscp cs2
class-map match-any BULK-DATA
 match ip dscp af11
 match ip dscp cs1
policy-map PE-FIVEOUR-CLASS-SP-MODEL
 class REALTIME
  priority percent 35
 class CRITICAL-DATA
  bandwidth percent 20
  random-detect dscp-based
 class PREFERRED-DATA
  bandwidth percent 15
  random-detect dscp-based
 class BULK-DATA
  bandwidth percent 5
  random-detect dscp-based
 class class-default
  fair-queu
  random-detect

Требования по уровню качества обслуживания к сети оператора

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

  • потери пакетов не более 1 процента;
  • односторонняя задержка не более 150 мсек (в соответствии со стандартом G.114);
  • колебания задержки не более 30 мсек.

Таким образом, операторская составляющая должна быть значительно меньше. Параметры SLA для Cisco Powered

Multiservice Networks показаны ниже: -потери пакетов не более 0.5 процента -односторонняя задержка между пограничными устройствами не более 60 мсек -колебания задержки не более 20 мсек Для того, чтобы добиться такого сквозного SLA клиенты и оператор должны скоординировать свои действия по классификации, конфигурации и интеграции решений QoS.

Рисунок №9. Требуемые параметры качества обслуживания

Модели настроек пограничных маршрутизаторов оператора

Последующие разделы иллюстрируют модели настройки пограничных устройств оператора.

Голосовой трафик

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

• Полисинг с учетом перегрузок (Congestion-aware policer)

class SP-VOIP
 priority [percent <%>|<kbps>] <burst>
 set ip dscp|prec <dscp|prec> or set mpls experimental <0 through 7> imposition

В этом режиме приоритетный трафик подвергается полисингу только в случае возникновения перегрузок на интерфейсе. Он инициируется опцией задания скорости в команде priority.

• Всегда работающий полисинг

class SP-VOIP
 priority police <bps> bc <bytes> conform transmit exceed drop
 set ip dscp|prec <dscp|prec> or set mpls experimental <0 through 7>

В этом режиме приоритетный трафик подвергается полисингу постоянно. Он инициируется командой police в описании приоритетного класса. Этот метод предпочтительнее для операторов желающих строго следовать условиям VoIP контракта.

Трафик данных

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

Минимальная полоса со сбросом с конца очереди (Tail-Drop)

Следующая конфигурация представляет собой самый простой способ классификации в класс данных. Классу гарантируется минимальная полоса пропускания и применяется сброс с конца очереди с указанием максимального размера очереди. Такой класс может занимать полосу выше сконфигурированной в случае, если она не используется другими классами в той же политике. Такая конфигурация редко используется на СЕ и РЕ устройствах, так как чаще всего для оптимизации TCP используют не сброс с хвоста очереди (tail-drop), а алгоритм WRED.

class SP-DATA
 bandwidth [remaining] [percent <%>|<kbps>]
 queue-limit <packets|bytes>

Конфигурация CE: Минимальная полоса с WRED и маркированием / перемаркированием DSCP

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

class SP-DATA
 bandwidth [remaining] [percent <%>|<kbps>]
 random-detect
 random-detect [dscp-based | prec-based]
 random-detect exponential-weighting-constant <expw>
 random-detect [dscp <dscp> | prec <prec>] <minth> <maxth> <mpd>
 set ip dscp <dscp> | ip prec <prec>

Конфигурация PE: Минимальная полоса и WRED

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

class SP-DATA
 bandwidth [remaining] [percent <%>|<kbps>]
 random-detect random-detect dscp-based | prec-based | discard-class-based
 random-detect exponential-weighting-constant <expw>
 random-detect dscp <dscp> <minth> <maxth> <mpd>

Команда random-detect discard-class-based используется для обеспечения прозрачности QoS, как описано в разделе “Прозрачность QoS с использованием Методов Туннелирования MPLS DiffServ”

Варианты конфигурации PE и CE: Максимальная полоса пропускания

Команда “bandwidth” гарантирует минимальную полосу для описываемого класса. В качестве вариации предыдущих конфигураций СЕ и РЕ в настройках класса для ограничения максимальной полосы пропускания можно использовать команду shape:

class SP-DATA
 bandwidth [remaining] [percent <%>|<kbps>]
 shape average <cir> <bc> <be>

Варианты конфигурации CE: ограничения на вход/выход

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

class SP-DATA
 bandwidth [remaining] [percent <%>|<kbps>]
 police <bps> bc <bytes> conform { action#1} exceed {action#2}

action#1 обычно одна из двух опций: transmit или set-dscp|prec-transmit <dscp|prec>. action#2 обычно одна из трех опций: drop или set-dscp|prec-transmit <dscp|prec> и / или set-frde-transmit или set-cos-transmit или set-clp-transmit. Первая опция action#2 реализует сброс пакетов. Вторая и третья – перемаркируют пакеты, то есть трафик вне контракта помечается. В случае использования последней опции над пакетом поступившем в соответствии с контрактными обязательствами производится два действия: маркировка на третьем уровне и маркировка фрейма на втором уровне. Опция frde-transmit  предназначена для Frame Relay, опция set-cos-transmit -для Ethernet/VLAN и опция set-clp-transmit -для АТМ.

Варианты конфигурации CE: ограничения на вход/выход с исключениями

В предыдущей модели весь трафик класса данных подвергался полисингу. Во многих случаях операторы хоте ли бы исключить какой-либо трафик того же класса из этого процесса. Например пробники Cisco Service Assurance Agent (SAA) посланные соответствующей раскраской в результате обработки могут быть сброшены или перекрашены. В следующей конфигурации используются иерархические карты правил для исключения трафика SAA из функции полисинга класса данных.

ip access-list extended SAA …
class match-all POLICED-TRAFFIC
 match not access-group name SAA
policy-map POLICING
 class POLICED-TRAFFIC
  police <bps> bc <bytes> conform {action#1} exceed {action#2}
policy-map CE-EDGE
&nbsp;…
 class SP-DATA
&nbsp;…
 service-policy POLICING

Варианты конфигурации CE и РЕ: ограничения на вход/выход и WRED

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

random-detect
random-detect dscp-based
random-detect exponential-weighting-constant <expw>
random-detect dscp <dscp_in> <minth_in> <maxth_in> <mpd>
random-detect dscp <dscp_out> <minth_out> <maxth_out> <mpd>

Использование трех профилей сброса в пределах одного класса – явление редкое из-за отсутствия ясной бизнес модели для такого сервиса. В типичной конфигурации  mpd = 1 и minth_in > maxth_ou, так что во время перегрузки трафик вне контракта будет сбрасываться более агрессивно, чем трафик в пределах контракта. В случае, когда WRED применяется совместно с полисингом для определения трафика в-и вне-контракта, критично чтобы выбор профиля WRED осуществлялся после исполнения полисинга. Это делается для того, чтобы в случае, если полисинг изменит значение DSCP, то профиль выбирался бы на основании этого нового значения.

Модели обработки трафика на третьем уровне и примеры конфигураций

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

Модель нескольких клиентов на нескольких DLCI

В настоящее время это самая распространенная модель предоставления сервиса третьего уровня. При этой модели на одном физическом интерфейсе конфигурируется n DLCI, по DLCI на клиента. На каждом под-интерфейсе/DLCI специфическая для клиента конфигурация MQC. Сервисные характеристики этой модели следующие:

  • Каждый клиент покупает агрегатную услугу (на все классы). Оператор гарантирует сервис используя формирование трафика DLCI (shaping) в соответствии с контрактной агрегатной полосой
  • Агрегат клиента может подразделяться на отдельные доступные полосы пропускания для различных классов.

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

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

Эта модель применима к FR/DLCI, ATM/PVC, и Ethernet/VLAN. Пример работы данной модели на Frame Relay показан ниже (конфигурация применима и для СЕ в направлении РЕ, и для РЕ в направлении СЕ).

policy-map CHILD
 class SP-VOIP
&nbsp; {VoIP-sub-model}
 class SP-DATA
 &nbsp;{Data-sub-model}
 class class-default
&nbsp; {Default-sub-model}
policy-map PARENT
 class class-default
  shape average <cir> <bc> <be>
  service-policy CHILD
map-class frame-relay FRTS
 service-policy output PARENT
interface SerialX/Y
 encapsulation frame-relay IETF
interface SerialX/Y.1 point-to-point
 frame-relay interface-dlci <dlci>
  class FRTS

Карты класса (map-class) привязаны к каждому point-to-point под-интерфейсу интрефейса Serial X/Y. Для поддержки различных скоростей доступа потребуется несколько FRTS карт класса. Каждый point-to-point под-интерфейс поддерживает только один DLCI.

Модель нескольких клиентов на нескольких DLCI с фрагментацией и чередованием второго уровня (L2 Fragmentation and Interleaving )

Эта модель является расширением предыдущей посредством добавления механизмов фрагментации и чередования второго уровня. Использование этого механизка позволяет фрагментировать большие фреймы данных и смешивать их с фреймами VoIP. Это приводит к исключению задержек трафика реального времени из-за задержек сериализации фреймов данных. Обычно фрагментацию включают в том случае, если худшая задержка VoIP пакета (в приоритетной очереди), возникающая из-за задержки сериализации больших фреймов данных, превышает бюджет задержки на канале доступа (15 мсек). Это обычно происходит на скоростях доступа до 768 kbps, но LFI может применяться и на интерфейсах до 2 Mbps. Обычно это зависит от размера передающей очереди (последний буфер FIFO между планировщиком и физическим проводом, цель которого довести утилизацию канала до 100 процентов). Эта модель применима к FR/DLCI с FRF.12. Похожий механизм – MLP LFI, может использоваться на сериальных каналах с MLP инкапсуляцией, ATM PVC с MLPoATM и даже Frame Relay каналах с MLPoFR. Эта модель не применима к Ethernet/VLAN и не поддерживается на сериальных каналах с HDLC инкапсулацией. Пример для Frame Relay приведен ниже. Конфигурация применима к СЕ в направлении РЕ, и на РЕ в направлении СЕ.

policy-map CHILD
&nbsp;…
policy-map PARENT
&nbsp;…
map-class frame-relay FRTS
 service-policy output PARENT
 frame-relay fragment <bytes>
interface SerialX/Y
 encapsulation frame-relay IETF
interface SerialX/Y.1 point-to-point
 frame-relay interface-dlci <dlci>
  class FRTS

Эта конфигурация может применяться совместно с адаптивным выравниванием потока и cRTP.

Модель нескольких клиентов на нескольких DLCI с адаптивным формированием потока (Adaptive Shaping)

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

  • Каждый клиент покупает агрегатную услуги (на все классы) с гарантированной минимальной (min) и максимальной (max) полосой. При наличии индикаторов перегрузки второго уровня (BECN/FECN для FR, пауза для Ethernet) используется адаптивное формирование потока для снижения скорости DLCI до гарантированного минимума. В случае отсутствия индикаторов перегрузки второго уровня скорость повышается до максимально гарантированной.
  • Агрегат клиента может разбиваться на отдельные полосы пропускания доступные для различных классов. В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации. Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов. Эта модель применима к /DLCI и Ethernet/VLAN, но не применима к ATM/PVC и PPP/HDLC. Для случая Frame Relay доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.
policy-map CHILD
…
policy-map PARENT
…
map-class frame-relay FRTS
 frame-relay adaptive-shaping
 service-policy output PARENT
interface SerialX/Y
 encapsulation frame-relay IETF
interface SerialX/Y.1 point-to-point
 frame-relay interface-dlci <dlci>
  class FRTS

Эта конфигурация может использоваться совместно с фрагментацией второго уровня и cRTP.

Модель нескольких клиентов на нескольких DLCI с применением cRTP

Эта модель – вариант модели нескольких клиентов на нескольких DLCI с добавлением RTP компрессии заголовка для сокращения занимаемой голосовым потоком полосы пропускания канала и для сокращения задержки сериализации VoIP (PQ) пакетов. Эта модель применима к FR/DLCI, ATM/PVCs с MLPoATM, и сериальным каналам  PPP/MLP/HDLC. Для случая Frame Relay доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.

policy-map CHILD
...
policy-map PARENT 
...
map-class frame-relay FRTS
 service-policy output PARENT
interface SerialX/Y
 encapsulation frame-relay IETF
interface SerialX/Y.1 point-to-point
 frame-relay interface-dlci <dlci>
  class FRTS
 frame-relay ip rtp header-compression

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

Модель одного клиента и одного DLCI

Эта модель – специфический вариант модели нескольких клиентов и нескольких DLCI и также очень распространена. Это прямое повторение основной модели, но с единственным сконфигурированным на основном интерфейсе DLCI. С помощью MQC конфигурируется основной интерфейс. Сервисные характеристики модели следующие:

  • Каждый клиент покупает агрегатную услугу (на все классы). Оператор гарантирует сервис либо посредством конфигурирования контрактной скорости на канале доступа, либо конфигурируя большую скорость и используя формирование трафика (shaping) на основном интерфейсе до контрактного значения.
  • Агрегат клиента может подразделяться на отдельные доступные полосы пропускания для различных классов. В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации. Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов. Эта модель применима только к каналам точка-точка, то есть сериальным HDLC/PPP/FR или Ethernet/VLAN. Так как модель не использует мультиплексирующие возможности второго уровня ее можно расширить и на PPP/HDLC. Может показаться излишним использование FR инкапсуляции. Но она применима по двум причинам:

FR – это универсальная инкапсуляция второго уровня, которая может применяться и для интерфейсов с одним подключенным клиентом и для интерфейсов с несколькими клиентами.

  • Поддержка IP QoS в IOS исторически лучше, чем на просто PPP/HDLC инкапсуляциях.
  • Маловероятно, что данная модель будет применяться на ATM интерфейсах, так как АТМ обычно используется из-за своих возможностей по мультиплексированию трафика и потому более применима к модели с множеством клиентов на одном интерфейсе.

Для случая Frame Relay доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.

policy-map CHILD
...
policy-map PARENT
...
map-class frame-relay FRTS
 service-policy output PARENT

В том случае, если формирование трафика (shaping) не используется на основном интерфейсе сервисную политику (service¬policy) CHILD можно применить непосредственно в карте класса (map-class) frame relay (тем самым сервисная политика PARENT нам больше не нужна).

interface SerialX/Y
 encapsulation frame-relay IETF
 frame-relay interface-dlci <dlci>
  class FRTS

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

Модель одного клиента и нескольких DLCI

При этой модели к физическому интерфейсу подключается один клиент и для него конфигурируется n DLCI. С помощью MQC конфигурируется основной интерфейс. Обычно эта модель используется в контексте RFC 2547 и каждый DLCI поддерживает логически отдельный сервис (на третьем уровне). Сервисные характеристики модели следующие:

  • Каждый клиент покупает агрегатную услугу (на все классы) в x Mbps, которая может быть меньше чем скорость интерфейса. Оператор обеспечивает контрактные обязательства формированием трафика (shaping) на интерфейсном уровне (не на уровне DLCI) до контрактного значения.
  • Агрегат клиента может подразделяться на отдельные доступные полосы пропускания для различных классов. В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации. Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов. Эта модель применима для FR/DLCI и Ethernet/VLAN. Эта модель не применима к ATM и PPP/HDLC.

До последнего времени эта модель не была применима на скоростях менее 2 Mbps вследствие отсутствия фрагментации на интерфейсном уровне. Для случая Frame Relay доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.

access-list 100 permit <…>
access-list 101 permit <…>
class-map match-any SP-VOIP
 match dlci 201
 match [access-group 100|protocol <prot>]
class-map match-all SP-DATA
 match [access-group 101|protocol <prot>]
policy-map child
 class SP-VOIP
  {VoIP-sub-model}
 class SP-DATA
  {Data-sub-model}
 class class-default
  {Default-sub-model}
policy-map PARENT
 class class-default
  shape average <cir> <bc> <be>
  service-policy CHILD
map-class frame-relay FRTS
 service-policy output PARENT
interface SerialX/Y
 encapsulation frame-relay IETF
 frame-relay class FRTS
interface SerialX/Y.1 point-to-point
 description e.g. Managed VoIP Service
 frame-relay interface-dlci 201
interface SerialX/Y.1 point-to-point
 description e.g. Intranet Service
 frame-relay interface-dlci 202
interface SerialX/Y.1 point-to-point
 description e.g. Internet Service
 frame-relay interface-dlci 203

Эта модель может использоваться совместно с фрагментацией второго уровня.

Модель нескольких клиентов и нескольких VLAN на каждого клиента

Эта модель – расширение модели нескольких клиентов на нескольких DLCI для Ethernet доступа. Каждому клиенту выделяется несколько VLAN, и каждый VLAN представляет свой сервис. Главная (parent) политика формирования трафика применяется для всей группы VLAN конкретного клиента. Второстепенная (child) политика буферизации применяется внутри главной политики. При этой модели на одном физическом интерфейсе конфигурируется множество VLAN. На физическом интерфейсе присутствует MQC конфигурация для каждого клиента. Для различия трафика клиентов используется match vlan type. Сервисные характеристики модели следующие:

  • Каждый клиент покупает агрегатную услугу (на все VLAN и все классы) в x Mbps. Оператор обеспечивает контрактные обязательства формированием трафика (shaping) для каждой группы VLAN каждого клиента до контрактного агрегатного значения каждого клиента.
  • С помощью конфигурирования min_cir (bandwidth) меньшим, чем cir (shape) можно обеспечить клиенту минимальную и максимальную гарантированную скорость.
  • Агрегат клиента может подразделяться на отдельные доступные полосы пропускания для различных классов. В случае исчерпания полосы агрегата данного клиента начинает работать механизм обратной связи на схему буферизации. Это приводит к дифференциации обслуживания очередей классов и работе механизмов сброса пакетов.

Эта модель применима к Ethernet/VLAN и не применима к FR/DLCI, ATM/PVC, и PPP/HDLC. Для случая Ethernet доступа пример конфигурации для случаев настройки интерфейсов от СЕ к РЕ и от РЕ к СЕ приведен ниже.

class-map CUSTOMER-A
 match vlan 1 2 3
class-map CUSTOMER-B
 match vlan 4 5 6
policy-map PARENT
 class CUSTOMER-A
  bandwidth <min_cir>
  shape average <cir> <bc> <be>
  service policy CHILD-A
class CUSTOMER-B
 bandwidth <min_cir>
 shape average <cir> <bc> <be>
 service policy CHILD-B

Такая конфигурация повторяется для всех n клиентов подключенных к GigabitEthernet0 интерфейсу.

policy-map CHILD-A
 class SP-VOIP
  {VoIP-sub-model}
 class SP-DATA
  {Data-sub-model}
 class class-default
  {Default-sub-model}
policy-map CHILD-B
 …
interface GigabitEthernet0
 service-policy output PARENT

Особенности дизайна магистрали оператора

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

  • Избыток по агрегатной полосе пропускания -это общая практика в операторских магистралях благодаря простоте реализации и использования. Предполагается, что на границе сети для агрегации трафика используется домен DiffServ. Исследования показали, что одним из вариантов поддержки в операторской сети параметров низкой задержки, колебаний задержки и потерь может быть закладка избыточных ресурсов по полосе пропускания примерно в два раза от реальной загрузки сети. К недостатком такого подхода можно отнести: ошибки при расчетах емкости сети, аварийные сетевые ситуации и неожиданный рост трафика или изменение его направления. А также факт отсутствия дифференциации между классами высокоприоритетного и низкоприоритетного трафика приводящий к тому, что в случае аварийных ситуаций и перегрузок происходит деградация высокоприоритетного трафика. Кроме того, этот метод может оказаться и не самым эффективным решением с точки зрения затрат.
  • DiffServ в магистрали—Использование DiffServ модели в магистрали позволяет операторам поддерживать несколько классов трафика с различными коэффициентами уровнями переподписки по классам. DiffServ в магистрали обеспечивает: или достижение тех же параметров SLA с использованием меньшей полосы пропускания, или поддержку большего агрегатного трафика при том же значении полосы пропускания сети. К недостатку этой модели можно отнести повышенную сложность при дизайне сети и ее обслуживании. В DiffServ магистрали не обязательно должно поддерживаться столько же классов, что и на границе сети (на интерфейсе РЕ-СЕ).

Пример DiffServ магистрали – Модель магистрали оператора с поддержкой трех классов сервиса

Как упоминалось ранее, нет необходимости поддерживать в магистрали то же количество DiffServ классов, что и на границе сети. Один из примеров реализации – это использование трех DiffServ классов в магистрали и пяти на пограничных устройствах (РЕ).

DiffServ классы оператора на границе сети DiffServ классы оператора в магистрали
Реальное время (Realtime) Реальное время (Core Realtime)
(Потоковое) Видео (Streaming Video) Критические данные (Core Critical Data)
Критические данные (Critical Data)
Объемные данные (Bulk Data)
По умолчанию (Best Effort) По умолчанию (Core Best Effort)

Определение магистральных классов

Магистральные классы определяются следующим образом:

  • Магистральный класс реального времени—Этот класс используется для приложений типа VoIP и интерактивное видео, которые требуют низких потерь пакетов (меньше 0.25 процентов), малой задержки и малого значения колебаний задержки (обычно по магистрали 5 мсек) и все это с определенным уровнем доступности. Этому классу может также потребоваться поддержка сохранения очередности пакетов в пределах потоков. Проектировать этот класс нужно всегда из соображений худшей задержки. Обычно избыточный трафик этого класса сбрасывается. В этот класс должны направляться пакеты с маркировкой EF и он должен обслуживаться в приоритетных очередях. Под приоритетную очередь следует отводить 25-33 процента полосы пропускания канала. WRED на этих очередях не применяют.
  • Магистральный класс критических данных -Этот класс используется для бизнес-критичных приложений, таких как SNA, SAP R/3, Telnet, и, возможно, внутренних Web-приложений. Он определяется в терминах задержки (RTT должен быть менее 250 мсек – порог человеческого восприятия задержки) и потерь (обычно это 1 процент, но возможно и достижение 0.1 процента). Колебания задержки для этого класса не важны и не определяются. Избыточный трафик этого класса обычно перемаркируется идентификатором “вне контракта” (меньшее значение EXP). В этом классе может обеспечиваться сохранение последовательности пакетов в потоке. В этот класс должны назначаться пакеты с маркировкой AF и ему должно выделяться до 90 процентов оставшейся полосы пропускания канала (после выделения полосы для PQ/EF трафика). Следует использовать WRED для оптимизации производительности TCP и применения политики сбросов пакетов для трафика выше контрактных обязательств.
  • Магистральный класс по умолчанию – Этот класс используют для клиентского трафика, который не был классифицирован как трафик реального времени или критических данных. Он определяется в терминах потери пакетов и доступности. Задержка и колебания задержки не важны для этого сервиса и их не следует определять. Таким образом, только 10 процентов оставшейся полосы пропускания канала (послу определения PQ) следует отводить на обработку этого класса. На границе сети оператора производится мапирование нескольких классов клиента в единый агрегатный магистральный класс оператора. В предыдущем примере несколько РЕ классов (потоковое видео, критические данные и объемные данные) мапировались в один магистральный класс критических данных. Это мапирование можно реализовать двумя способами:
  • Магистральный класс проверяет установку нескольких значений DSCP. Применительно к предыдущему примеру, если DSCP AF31 представляет на границе критические данные, DSCP AF21 — (потоковое) видео и DSCP AF11 – объемные данные, то магистральный агрегатный класс (класс критических данных) проверяет на соответствие значениям  DSCP AF31, AF21 и AF11.
  • Если в магистрали используется MPLS, то пограничный маршрутизатор может устанавливать значение поля MPLS EXP (3 бита) как функцию полученного DSCP. Применительно к тому же примеру, если в качестве критерия принадлежности к магистральному классу (критических данных) служит MPLS EXP = 3, то РЕ пограничный маршрутизатор оператора должен устанавливать значение MPLS EXP в 3 для всех пакетов со значением DSCP AF31 (пограничный класс критических данных), AF21 (пограничный класс потокового видео) и AF11 (пограничный класс объемных данных).

Заключение

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

(Исходник)

Leave a comment Posted on Tech articles

Безопасность маршрутизаторов Cisco

Маршрутизатор — это «первая линия обороны» нашей корпоративной сети непосредственно соприкасающаяся с Internet. Они часто применяются в качестве ключевых элементов в системах защиты сетей (например, firewall для фильтрации пакетов и ограничения прохождения определенного IP -трафика). Наиболее широко распространенным сейчас является оборудование фирмы Cisco Systems, которое благодаря различной реализации своей «фирменной» операционной системы Cisco IOS может приобретать свойства, необходимые администраторам.

А как его (маршрутизатор Cisco) защитить?

Список команд

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

Используйте Чтобы
enable secret Задать пароль для привилегированного доступа.
service password-encryption Обеспечить минимальную защиту для паролей в конфигурации.
no service tcp-small-servers
no service udp-small-servers		 Избегать использования простых сервисов для DoS и других атак.
no service finger Избегать распространения информации о пользователях.
no cdp runningno cdp enable Избегать распространения информации об этом маршрутизаторе на соседние устройства.
ntp disable Предотвратить атаки на сервис NTP.
no ip directed-broadcast Помешать атакующим использовать маршрутизатор для smurf атак.
transport input Указать какие протоколы могут быть использованы удаленными пользователями чтобы войти через VTY или получить доступ к его TTY портам.
ip access-class Указать с каких IP адресов пользователи могут подключаться к TTYs или VTYs. Зарезервировать один VTY для доступа с рабочей станции администратора.
exec-timeout Не занимать VTY бесконечно долго бездействующей сессией.
service tcp-keepalives-in Обнаруживать и удалять «зависшие» сесии, освобождая используемые VTY.
logging buffered buffer-size Сохранять логируемые данные в буфере оперативной памяти маршрутизатора. В последних версиях IOS этот размер может идти совместно с параметром urgency threshold.
ip access-group list in Отбрасывать пакеты с поддельным IP адресом. Отбрасывать входящиеICMP redirects.
ip verify unicast rpf Отбрасывать IP пакеты в с поддельным адресом источника в случае симметричной маршрутизации на маршуризаторах поддерживающих CISCO Express Forwarding (CEF). Данная проверка известна как reverse path forwarding (RPF).
no ip source-route Отбрасывать IP пакеты, в которых включена опция source routing. Таким образом злоумышленник не получит обратно ответ на посланный пакет, если он использовал поддельный IP адрес.
access-list number action criteria log
access-list number action criteria log-input		 Включить логирование пакетов удовлетворяющих определенному условию из access-list. Используйте log-input если это возможно в версии вашего IOS.
scheduler-intervalscheduler allocate Защититься от флуда и позволить работать важным процессам.
ip route 0.0.0.0 0.0.0.0 null 0 255 Быстро удалять пакеты посланные на несуществующие адреса.
distribute-list list in Фильтровать получаемую информацию о маршрутах чтобы предовратить использование неверных маршрутов.
snmp-server community something-inobvious ro listsnmp-server community something-inobvious rw list Включить SNMP версии 1, настроить аутентификацию и разрешить доступ только с некорых IP адресов. Используйте SNMP версии 1 только, если версия 2 недоступна. Следите за наличием снифферов в сети. Включите SNMP только если он нужен в вашей сети. Не настраивайте доступ на запись, если он вам не нужен.
snmp-server party…
authentication md5 secret …		 Сконфигурировать аутентификацию посредством MD5 для SNMP версии 2. Включайте SNMP только, если он нужен в вашей сети.
ip http authentication method Производить аутентификацию соединений по HTTP (если вы включили HTTP сервер на вашем маршрутизаторе).
ip http access-class list Дальнейшее управление доступом к HTTP серверу, разрешая его только с некоторых хостов (если вы включили HTTP сервер на вашем маршрутизаторе).
banner login Установить предупреждающее сообщение для показа всем пользователям, кто пытается залогиниться на маршрутизатор.

Заметки по увеличению безопасности маршрутизатора Cisco

1. Правильный выбор пароля (не менее 8 хаотично выбранных символа,
использование enable secret).

    enable secret секретный_пароль
    service password-encryption
    username admin privilege 5 password мойпароль
    aaa new-model
    aaa authentication username-prompt "login: "
    aaa authentication login default local
    aaa authentication login CONSOLE none
    aaa authorization exec local if-authenticated 

2. Ограничение доступа на Cisco (доступ только с IP админов) и защита от сниффинга (использование коммутаторов).
   access-list 105 permit ip host ip_админа any
   access-list 105 deny ip any any
   line vty 0 4
     access-class 105 in
     login local
     exec-timeout 2 0

3. Ограничение доступа по SNMP только с определенных IP (администраторы, мониторинг и биллинг), изменение название community public на что-нибудь бессвязное, например kdjfgsdkgj.
   access-list 15 permit ip host ip_которому_разрешено_snmp
   access-list 15 deny any
   snmp-server community kdjfgsdkgj RO 104

4. Отключаем все лишние сервисы (cdp - cisco discovery protocol), например:
   no ntp enable
   no cdp running
   no cdp enable
   no service finger
   no service tcp-small-servers
   no service udp-small-servers
   service tcp-keep-alives-in
   no ip http server

5. Настраиваем ACL (access lists), минимум что нужно сделать (против спуфинга):
   (правила просматриваются в порядке следования, срабатывает первое подходящее 
   правило)
   access-list 100 deny ip 127.0.0.0 0.255.255.255 any
   access-list 100 deny ip 10.0.0.0 0.255.255.255 any
   access-list 100 deny ip 224.0.0.0 31.255.255.255 any
   access-list 100 deny ip host 0.0.0.0 any
   access-list 100 deny ip host 255.255.255.255 any
   access-list 100 deny ip 192.168.0.0 0.0.255.255 any
   access-list 100 deny ip 172.16.0.0 0.0.255.255 any
   access-list 100 deny ip наша_сеть маска_нашей_сети any
   access-list 100 deny icmp any any redirect.
   access-list 100 permit ip any any
   access-list 101 permit ip наша_сеть маска_нашей_сети any
   access-list 101 deny ip any any

   # Затем привязываем ACL к интерфейсу:
   interface ethernet 0
     ip access-group 100 in
     ip access-group 101 out

6. Защищаемся от флуда (и прочей нечисти), на каждом интерфейсе:
   # чтобы трафик на несуществующие ip не играл в пинг-понг
   ip route 0.0.0.0 0.0.0.0 null 0 255
   # защита от флуда
   scheduler interval 500   
   no ip source-route
   interface ethernet 0
    no ip directed-broadcast
    no ip proxy-arp
    no ip redirects
    no ip unreachables

Cпособы повышения защищенности маршрутизаторов CISCO

Пароли

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

enable secret
Данная команда используется для установки паролей, которые предоставляют привилегированный доступ администратору в IOS. Данный пароль должен быть всегда установлен. Нельзя устанавливать enable password , т.к. данная команда использует слабую криптографию.

service password-encryption
Данная команда позволяет зашифровать пароли, CHAP секреты и другие данные, находящиеся в конфигурационном файле.

 

Контроль доступа

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

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

Основной способ доступа 
Существует достаточное количество способов для подключения к маршрутизатору. CISCO IOS в зависимости от конфигурации поддерживает соединения посредством telnet, rlogin, SSH, LAT, MOP, X.29, V.120. Локальные асинхронные терминалы и модемы используют стандартные линии — TTY. Удаленные сетевые соединения (независимые от протоколов) используют виртуальные TTY (VTY). Для защиты необходимо на все линии доступа установить пароли, для VTY возможна команда no password для защиты.

По умолчанию удаленный пользователь может установить соединение с TTY через сеть, так называемый «reverse Telnet», что позволяет данному пользователю работать с модемом или терминалом, подсоединенным к данному TTY. Для защиты необходимо работать с командой transport input none , которая запрещает принимать соединения из сети. Если есть возможность , то необходимо разнести dial-in и dial-out модемы и запретить использование reverse Telnet для линий, которые используются в dial-in.

Управляющий VTY
Любые VTY должны быть сконфигурированы для того, чтобы принимать соединения только по протоколам, которые нужны. Это можно сделать с помощью команды — transport input. Например, по VTY ожидается прием только сессии telnet, для этого используем команду transport input telnet. Для поддержки telnet и SSH необходимо ввести команду transprot input telnet ssh. Также можно ограничить доступ с определенных адресов с помощью ip access-class.

В СISCO IOS используется ограниченное количество VTY (обычно пять). Когда все VTY используются, больше никто подсоединиться не может. В этом и есть возможность использования DoS атаки. Способ защиты — ограничить доступ с помощью ip access-class. Например, для одного VTY используется общий доступ, а для четырех — только с одной рабочей станции.

Также можно использовать команду exec-timeout для ограничения времени атаки.

Можно использовать команду для TCP keepalive входящих соединений service tcp-keepalive-in для защиты от атак на хосты.

Желательно отключить возможность использования отличных от IP протоколов для доступа к VTY.

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

 

Плохо сконфигурированные сервисы управления

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

SNMP

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

Если все-таки необходимо использовать версию 1, то необходимо быть внимательным при выборе community string (нельзя использовать public или private). Необходимо избегать использования одних и тех же community string для различных устройств. Если возможно, то установить для periodic SNMP ver 1 polling в read-only community string.

Для версии 1 необходимо использовать ACL на команде snmp-server community для ограничения доступа на станции управления. Нельзя использовать команду snmp-server community в окружении, где используется версия 2 (переключает в версию 1).

Для версии 2 необходимо сконфигурировать защиту с помощью команд authentication и md5 в конфигурации snmp-server party. Если возможно, то лучше использовать различные секреты MD5 для каждого маршрутизатора.

HTTP
Для облегчения конфигурирования маршрутизатора есть возможность «поднять» на нем HTTP сервер. Пароль передается в открытом виде.

Для защиты необходимо ограничить перечень IP-адресов путем ip http access-class. Также можно использовать аутентификацию с использованием команд ip http authentication.

 

Управление и доступ через Интернет (или другие незащищенные сети)

Многие пользователи управляют своими маршрутизаторами удаленно, и часто через Интернет. Все схемы удаленного управления подвержены атакам, например, Packet Sniffers. Злоумышленники очень часто взламывают машины ISP или другие компьютеры в Сети и устанавливают программы-сниферы, которые мониторят весь трафик, пытаясь заполучить парольную фразу (если используется telnet, HTTP, snmp v.1). Защита — использование технологии S\Key, Kerberos, RADIUS, TACACS+. Для выявления сниферов можно использовать: http://www.l0pht.com/antisniff

 

Логировние

Способы ведения логов в CISCO

  • AAA logging — ведение записей о пользователях , которые подключаются.
  • SNMP trap logging — посылка данных об изменениях в системном статусе.
  • system logging — записывает огромное множество событий: logging console logging ip-address, logging trap logging monitor, termonal monitor logging buffered

Сохранение информации 
По умолчанию логируемая информация отсылается только на асинхронный консольный порт.

Почти все маршрутизаторы сохраняют информацию logging в local RAM buffer, имеющий конечный размер ( show memory, logging buffered buffer-size).

Также можно сохранять данные на syslog сервер, logging server ip-address, logging trap urgency.

Если маршрутизатор имеет real-time clock или запущен NTP, то можно записать лог с time-stamp — service timestamps log datetime msecs.

Запись нарушений списков доступа
Если используются списки доступа для ограничения трафика, есть возможность записи их нарушений. Команды — в старых версиях — log, в новых — log-input.

 

Защита IP-маршрутизации

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

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

Защита с помощью ACL
К сожалению, нет общих примеров по конфигурации ACL, каждый раз поход различный. Однако основа одна: отбросить пакет, который пришел с интерфейса, с которого данный адрес прийти не может. Например, система имеет два интерфейса, один из них смотрит в сеть Интернет, а другой в сеть Интранет. Все пакеты, принятые из сети Интернет с адресами источника внутренней сети (адреса Интранет), будут отброшены. Если CPU позволяет, то anti-spoofing должен быть включен на каждом интерфейсе.

Пример:

access-list number deny icmp any any redirect
access-list number deny ip 127.0.0.0 0.255.255.255 any
access-list number deny ip 224.0.0.0 31.255.255.255 any
access-list number deny ip host 0.0.0.0 any

Anti-spoofing with RPF checks
Практически во всех CISCO IOS , которые поддерживают CISCO Express Forwarding (CEF), существует возможность «заставить» маршрутизатор проверять source address каждого пакета. Это будет работать только в случае, если маршрутизация симметричная. Если сеть будет построена так, что путь трафика от хоста А до хоста В будет проходить другим путем, чем трафик от B до A, проверка всегда будет давать неверный результат, и связь между хостами будет невозможна. Данная асимметричная маршрутизация обычно используется на Internet core. Данная проверка известна как reverse path forwarding (RPF) и включается с помощью команды ip verify unicast rpf.

Controlling Directed Broadcasts
Для атаки типа «smurf» обычно используется IP directed broadcasts.

IP directed broadcast — это пакет, который посылается на адрес broadcast подсети, к которой посылающая машина напрямую не подключена. Directed broadcast маршрутизируется через сеть как обыкновенный пакет unicast пока не достигнет подсети назначения, где и будет конвертирована в link-layer broadcast. Согласно архитектуре протокола IP только последний маршрутизатор в цепочке, тот который напрямую подсоединен к подсети-назначения, может идентифицировать directed broadcast.

При атаке типа «smurf» атакующий посылает пакеты ICMP echo requests, используя сфальсифицированный адрес источника, и все хосты подсети отвечают на подмененный адрес источника.

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

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

http://users.quadrunner.com/chuegen/smurf.cgi

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

IP Source Routing
Протокол IP поддерживает опцию source routing, которая позволяет отправителю IP-пакета контролировать путь пакета до получателя. Ранние реализации IP отрабатывали пакеты source-routed неправильно, что могло в результате посылки на нее пакета с опцией source routing привести в зависанию машины.

Маршрутизаторы CISCO с установкой no ip source-route не будут пересылать пакеты IP, в которые будет включена опция source routing.

ICMP Redirects
Сообщение ICMP redirect «заставляет» конечное СВТ использовать указанный маршрутизатор для достижения определенной точки в сети. В нормально функционирующей сети маршрутизатор посылает пакеты redirects только хостам, расположенным в локальной подсети, ни один конечный узел не посылает данные пакеты, и ни один такой пакет не проходит больше одного сетевого hop. Однако атакующий может обойти эти правила . Хорошая идея -отфильтровать входящие ICMP redirects на входящем интерфейсе любого маршрутизатора, находящегося на границе между административными доменами.

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

Routing Protocol Filtering and Authentication
Если используется динамическая маршрутизация, которая использует аутентификацию, то ее необходимо использовать. Это позволяет избежать проблемы подмены данных маршрутизации.

В части ISP или других больших сетях целесообразно использовать фильтрацию протоколов маршрутизации с использованием команды distribute-list in. Например, если вы используете динамическую маршрутизацию для связи с пользовательской «stub» сетью, вам не нужно принимать данные об обновлении маршрута с данной сети.

 

Защита от флуда

Множество атак типа «Отказ в обслуживании» (DoS) основаны на пересылке бесполезных пакетов. Данные действия занимают полосу пропускания, снижают время ответа хостов и могут привести к перезагрузке маршрутизаторов.

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

Транзитный флуд
Существует возможность использования CISCO’s quality of service (QoS) для защиты хостов от данных атак. Можно использовать — weighted fair queueing (WFQ). WFQ устанавливается по умолчанию для низкоскоростных линий во многих версия ОС. Также можно использовать committed access rate (CAR), generalized traffic shaping (GTS) и custom queuing.

Если планируется использовать QoS для контроля трафика, очень важно понимать, как это работает. Например, WFQ более эффективен против floods, чем против SYN floods, потому что обычный ping flood для WFQ является одиночным трафиком, а для SYN flood каждый пакет является отдельным потоком.

CISCO обеспечивает два различных способа уменьшить опасность от атаки типа SYN flooding. Способ «TCP Intercept» используется в маршрутизаторах модели 4000 или выше. Например, CISCO IOS Firewall Feature Set включает различные способы защиты от SYN flood.

Самозащита маршрутизатора
Прежде всего необходимо защитить сам маршрутизатор от атак и после этого необходимо защищать хосты, стоящие после него. Switching Modes and CISCO Express Forwarding

Режим — CEF switching mode, являющийся доступным в версиях ПО 11.1CC, 11.1CT, 11.2GS, и 12.0. Позволяет быстрее переключать трафик, чем обычная маршрутизация.

Хотя многие атаки типа DoS пересылают все пакеты на один или несколько хостов, много атак типа SYN flooding используют изменяющийся адрес источника. Хост, который атакуют, отвечает на SYN flood пакеты, создавая трафик с различными адресами destinations. При этом рекомендуется использовать CEF.

Scheduler Configuration
Когда маршрутизатор CISCO находится в режиме fast-switching большого количества пакетов, есть возможность его «загрузить» только работой на ответ , другая работа не будет проводиться. Данный эффект может быть снижен путем использования команды scheduler interval. Типичная конфигурация использует команду scheduler interval 500, которая показывает , что задача будет выполняться каждые 500 milliseconds.

Новые платформы фирмы CISCO используют команду scheduler allocate вместо команды scheduler interval.

 

Возможно ненужные сервисы

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

TCP and UDP «Small Services»
По умолчанию CISCO, начиная с версии 11.3, поднимает «small services»: echo, chargen и discard. Данные сервисы , особенно их UDP версии, могут использоваться для DoS атаки на маршрутизатор.

Например, атакующий может послать DNS пакеты с подмененным адресом источника DNS сервера и портом (53). Если данные пакеты будут направлены на порт CISCO’s UDP echo port, то маршрутизатор будет посылать DNS пакеты на сервер с вопросом. Ни один ACL не будет это отслеживать.

Для отключения необходимо использовать команду no service tcp-small-servers и no service udp-small-servers.

Finger
Маршрутизатор CISCO обеспечивает сервис «finger», который позволяет уточнить, кто подключен из пользователей. Отключается командой no service finger.

NTP
Network Time Protocol (NTP) не является опасным сервисом, но любые не нужные сервисы потенциально опасны. Для отключения используйте команду no ntp enable.

CDP
CISCO Discovery Protocol (CDP) используется для обмена данными между устройствами CISCO. Отключение производится командой no cdp running. CDP может быть поднят на каком-то из интерфейсов, отключение — по команде no cdp enable.

 

Leave a comment Posted on Tech articles

Настройка времени на Cisco

Для работы с журналами событий маршрутизатора Cisco, списков временного доступа, а также для синхронизации происходящих событий и отладки работы маршрутизатора Cisco необходимо использовать команду clock и сервера NTP (Network Time Protocol). Они отвечают за правильное состояние времени на маршрутизаторе, обеспечивая высокую точность измерения – до миллисекунды. Также важен автоматический переход на летнее время.

Настроить время не сложно, достаточно выполнить комманду:

router(config)#сlock set hh:mm:ss Nov 4 2012
router(config)#clock timezone MSK

Месяц должен соответствовать европейскому формату. Мы указали текущее время, дату и часовой пояс. Теперь нужно настроить синхронизацию с сервером NTP — этим мы получим ВСЕГДА точное время.

router(config)#ntp server ru.pool.ntp.org 
router(config)#ntp update-calendar

Для синхронизации выбран (территориально) пул адресов NTP-серверов ru.pool.ntp.org. Можно указывать нужный ip или доменное имя.

ntp update-calendar используют для обновления hardware clock (calendar). Но и на этом настройка времени не закончена. Нужно автоматизировать переход на летнее время. Для этого:

router(config)#clock summer-time MSK recurring last Sun Mar 2:00 last Sun Oct 2:00

Теперь в последнее воскресенье марта, в 02:00 переходим на летнее время. И аж до последнего воскресенья октября, 02:00.

Для того, чтобы временя в пределах локальной или региональной сети было одинаковым, используется протокол NTP (Network Time Protocol). Принцип работы этого протокола в том, что в сети задается один или несколько мастеров времени, а все остальные  находящиеся в этой сети маршрутизаторы при включении устанавливают свой clock по данным мастера и в дальнейшем периодически синхронизируют с ним свое точное время. На сервере времени, в качестве которого обычно используется как раз маршрутизатор с энергонезависимой памятью календаря необходимо ввести команду:

router(config)#ntp master

На других маршрутизаторах Cisco достаточно прописать указание на NTP-сервер:

router(config)#ntp server 192.168.0.100

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

router(config)#ntp server 192.168.0.100 prefer
router(config)#ntp server 191.168.0.200

Если все настроено правильно, то по команде show ntp status можно получить информацию, включающую адрес мастер-сервера, с которым синхронизировано время по протоколу NTP, текущие дату и время, а также расхождение времени с сервером.

router#show ntp status
Clock is synchronized, stratum 3, reference is 192.168.0.100
nominal freq is 250.0000 Hz, actual freq is 250.0001 Hz, precision is 2**18
reference time is CE9032F2.A3B00DF6 (16:38:42.639 EET Mon Oct 26 2009)
clock offset is 9.3036 msec, root delay is 63.63 msec
root dispersion is 143.59 msec, peer dispersion is 0.40 msec

Еще одна полезная команда — это show ntp associations, из результата которой мы видим прописанные на данном маршрутизаторе NTP-сервера, какой из них является master, кто от кого получает время, к какому слою принадлежит маршрутизатор (stratum — чем меньше значение, тем точнее его время) и некоторые другие параметры.

router#show ntp associations

      address         ref clock     st  when  poll reach  delay  offset    disp
 ~212.111.205.110  0.0.0.0          16     -  1024    0     0.0    0.00  16000.
 ~194.44.35.24     0.0.0.0          16     -  1024    0     0.0    0.00  16000.
*~192.168.0.100    62.149.0.30       2    28    64  377     1.6    9.54     0.3
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

По умолчанию на маршрутизаторах Cisco включены timestamps debug и timestamps log, которые отображают время события (заносимого в журнал или отображаемого в debug-режиме) в формате, привязанном к правильному текущему времени – то есть заданному при настройке. Если они сервисы отключены, то включить их можно следующими командами:

router#service timestamps debug datetime localtime
router#service timestamps log datetime localtime

Проверено на 2800.

Leave a comment Posted on Tech articles

Обновление сертификата на маршрутизаторе Cisco

IPSec с использованием сертификатов. На маршрутизаторе также установлен сертификат. Но его периодически нужно обновлять. И вот как это делать.

Обновление существующего сертификата на маршрутизаторе Cisco

Включим terminal monitor, чтобы получить логи:

Router# terminal monitor

В режиме конфигурации удаляем старый сертификат:

Router(config)# no crypto pki certificate chain %TRUSTPOINT%

Получаем сертификат CA-сервера:

Router(config)# crypto pki authenticate %TRUSTPOINT%

Запрашиваем собственный сертификат:

Router(config)# crypto pki enroll %TRUSTPOINT%

При отправке необходимо указать пароль (если он не указан в транспоинте). Так как у нас виндовый центр сертификации, то пароль мы можем узнать на IIS сервера: Default Web Site — CertSrv — mscep — Browse.

Если все ок — то получим ответ:

CRYPTO_PKI: Certificate Request Fingerprint MD5: BB0EE109 A7165C7E C9574C79 6211ACF7
CRYPTO_PKI: Certificate Request Fingerprint SHA1: 2E95A239 93D8546C E19F709B A4CD9C5E A15FA943
%PKI-6-CERTRET: Certificate received from Certificate Authority

Если же пароль неправильный или ошибка в конфигурации, то получим в консоль ответ:

%PKI-6-CERTRENEWAUTO: Renewing the router certificate for trustpoint %имятрастпоинта%
CRYPTO_PKI: Certificate Request Fingerprint MD5: DBC61896 0CF48A68 259D80B7 E831F96E
CRYPTO_PKI: Certificate Request Fingerprint SHA1: FD7D677B 40A6F538 9B6AB6CF BD0F6360 8956CE90
%PKI-6-CERTREJECT: Certificate enrollment request was rejected by Certificate Authoritypassword

Тогда на сервере перезапускаем центр сертификации и IIS. После этого смотрим еще раз пароль (должен быть другим) и повторяем:

Router(config)# crypto pki enroll %TRUSTPOINT%

Запрос сертификата «с нуля» на маршрутизаторе Cisco

Генерируем пару ключей:

Router(config)# crypto key generate rsa

Создаем трастпоинт:

Router(config)# crypto pki trustpoint %TRUSTPOINT%

И указываем URL для запроса сертификатов:

Router(ca-trustpoint)# enrollment url http://%CA%:80/certsrv/mscep/mscep.dll

Получаем сертификат CA-сервера:

Router(config)# crypto pki authenticate %TRUSTPOINT%

Запрашиваем собственный сертификат:

Router(config)# crypto pki enroll %TRUSTPOINT%

http://www.rublin.org/article/cisco

Leave a comment Posted on Tech articles

Резервное копирование баз в MS SQL

Для резервного копирования баз данных сервера MS SQL обычно используют SQL Server Agent.

Проблема появляется, когда есть только бесплатная версия MS SQL — Express.

В ней отсутствует SQL Server Agent. И хотя в SQL Server 2008 Express такая служба и есть, но она не запускается, а выдает ошибку SQLServerAgent could not be started (reason: Error creating a new session).
Странно, — оставлять службу, но не позволять ее запускать.

Эту проблему решает простой скрипт:

REM База данных
set DB=DB01
REM Путь до папки хранения бэкапов
set backup_path_local=d:\backup\
REM Путь до сетевого хранилища
set backup_path_remote=\\serverbackup\backup$\SQL_Database\
REM Запуск резервного копирования с помощью утилиты Sqlcmd
Sqlcmd -Q "BACKUP DATABASE [%DB%] TO  DISK = N'%backup_path_local%%computername%_%DB%.bak' WITH NOFORMAT, INIT,  NAME = N'%DB%-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10" -t 60000
REM Перемещение копии в сетевое хранилище
move %backup_path_local%%computername%_%DB%.bak %backup_path_remote%

Нужно только ввести собственные параметры в переменные DB, backup_path_local и backup_path_remote