antiCisco blogs

Опубликовано Fedia 4 Ноябрь , 2012

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

Попробую здесь, в первой статье такого рода, заложить некие основы будущих циклов. Как мне кажется, такие публикации должны содержать:
1. Введение, где простым русским языком описано, что и зачем делается
2. Описание топологий
3. Описание настроек
4. Методика проведения тестов
5. Результаты
6. Краткие, по возможности, сенсационные выводы 🙂

Итак, приступим!

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

Топология:
Был собран вот такой стенд (см. Рисунок):

Справа — головной офис (там сервер и CUCME на 2901), слева — «филиал» (там клиент и 1841 в качестве пограничного маршрутизатора)

UPD: картинка съехала, почему-то. Справа, уже за пределами центрального фрейма, тоже воткнута IXIA. Туда ведет красный линк 🙂

Настройки:
Была заготовлена политика QoS с выделением приоритетной полосы для пары приложений (голос, спецприложение ГИС), остальной трафик был принудительно зашейплен до 2мбит/сек

Кому интересны сами настройки:

На 1841, «филиальном»:


ip access-list extended GIS
permit ip 10.30.1.0 0.0.0.255 host 10.40.1.2
!
class-map GIS
match ip access-list name GIS
!
class-map VOICE
match protocol skinny
match protocol rtp audio
!
policy-map GIS
class GIS
priority 100
class VOICE
priority 300
class class-default
fair-queue
!
policy-map 2MB
class class-default
shape average 2000000
service-policy GIS
!
crypto ipsec transform-set AES256SHA esp-aes-256 rsp-sha-hmac
crypto ipsec profile IPSEC
set transform-set AES256SHA
!
!
interface tunnel 0
service-policy out 2MB
tunnel protection ipsec profile IPSEC
tunnel mode gre


На 2901 («Центральном», на котором регистрировались телефоны) тоже самое, за исключением:

ip access-list extended GIS
permit ip host 10.40.1.2 10.30.1.0 0.0.0.255


Методика проведения тестов:
1. Были проведены тесты без нагрузки (голос, ГИС)
2. Были проведены тесты с разным уровнем нагрузки (75% или 100% загрузки канала, пакеты 100, 400 или 1400 байт) и разными приложениями.

Для загрузки 100% канала делали 2 мбит/сек «сырого» трафика на L2 на обеих площадках. Для тестов с загрузкой 75% канала подбирали индивидуально параметры для разных размеров пакетов.

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

Во-первых, при большой нагрузке ТСР сессия, если она уже установлена, работает довольно устойчиво, а если надо устанавливаться заново — практически нет шансов (проверяли на Skinny). Сняли внешние симптомы сильно забитой полосы — телефон начинает периодически терять «связь с реальностью». Можно теперь предсказывать проблемы.

Во-вторых, как вы думаете (микроопрос): в приведенной выше топологии при подаче нагрузки 2мбит/сек 100 байтовыми пакетами, какова была загрузка CPU у маршрутизатора 1841?
1. 20-30%
2. 30-40%
3. 40-50%
4. 50-60%
5. 60-70%
6. 70-80%
7. 80-90%
8. 90-100%

а если пакеты — 400 байтовые?

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

______________
UPD 10.11.12
Ответ: в первом случае загрузка была ровно 100%, во втором — около 50% (49-52%).
______________

В-третьих, результаты очень стабильны. Т.е. если мы н обрабатываем (теряем) какую-то часть пакетов, этот процент практически не меняется. Отсюда вывод: я наверно пересмотрю свое мнение,что при достижении 80% порога на рутерах происходят «неправильные» изменения стабильности работы, непредвиденные дропы и просадки по работе. В данном тесте все было как раз наоборот: в сложных условиях стабильность работы сохранялась

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

Выводы:
Сенсации не получилось, но мы тут и не гнались. В-общем, гвозди забивали. С той задачей, которую мы решали, справилось бы и бесплатное ПО. Однако, уровень наглядности, количество настраиваемых параметров и стабильность результата вне всяких сомнений. Лиха беда начало: осваиваем и L4 нагрузку, и L7. Будем сервисы мучать, будем искать неизвестное. Ждите новых статей, а пока поиграйте в угадайку про нагрузку CPU. Удачи!

Сергей Федоров

 

Метки: IXIA
Опубликовано: Маршрутизаторы и коммутаторы