antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 8 Апрель , 2013

          Опишем схемы тестирования и методику определения производительности различного оборудования при использовании IXIA и ПО IxNetwork. Данная статья является логическим продолжением статьи:
«А в попугаях-то я гораздо длиннее» или как мы Циску Иксией мерили
          Статья носит формальный характер, но её прочтение рекомендуется для правильного восприятия результатов различных тестов, которые будут представлены в последующих статьях.

          Схемы тестирования

          Схемы тестирования стандартные: никаких лишних устройств, тестируемое устройство — DUT (Device Under Test) подключается физически напрямую двумя портами к IXIA. Один порт IXIA используем как источник трафика, другой – как получатель.

IXIA_one_device
                                                              Рисунок 1. Схема с одним DUT

          Такая схема позволяет протестировать достаточно большой список функций на маршрутизаторах:
1) Простая маршрутизация пакетов
2) NAT (несколько тестов: а) NAT включен, но трафик не попадает под правила трансляций б) NAT в) PAT)
3) PBR (несколько тестов: а) PBR включен, но трафик не попадает под правила PBR б) PBR c ACL с использованием только IP адресов в) PBR с использованием TCP/UDP портов)
4) Access-lists: а) поток разрешается первой строкой ACL б) поток разрешается 25-й строкой ACL)
5) QoS (несколько тестов: а) Классификация и маркировка на входящем интерфейсе б) Классификация, шейпинг с вложенными очередями по выходу в) IP NBAR Protocol Discovery)
6) Firewall (несколько тестов: а) CBAC б) ZBF)
7) Комплексные тесты: NAT+Firewall, NAT+QoS+Firewall

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

IXIA_two_device
                                                              Рисунок 2. Схема с двумя DUT

          Схема с двумя устройствами помимо всех тестов, приведённых для схемы с одним DUT, позволяет протестировать функции туннелирования. Список тестов, которые можно организовать при такой схеме, включает в себя:
1) IPSec
2) GRE
3) GREoIPsec
4) GRE + QoS
5) GREoIPSec + QoS
6) Комплексные тесты: GRE+IPSec+QoS+NAT+Firewall; GRE+ QoS+NAT+Firewall.

          Методика определения пропускной способности

          Напомню, что мы ставили себе следующие цели:
1) Определить скорость передачи, при которой прекращаются потери пакетов (loss < 0.002, т.е. допускаем потери двух пакетов из тысячи)
2) Определить скорость передачи, при которой загрузка процессора становится меньше 75%

          Тесты проводятся односторонними UDP потоками. Для большинства тестов будем приводить результаты с использованием 10 односторонних UDP потоков с адресами источника от 172.25.1.1 до 172.25.1.10 и общим адресом получателя 172.25.2.1; source-port = 4000; destination port = 5000. Почему десять потоков? Мы проводили тесты с разным количеством потоков: от одного до 200, скрипт позволяет нам менять этот параметр. Использование одного потока сильно отличается от реальности, а использование 100 или 200, как показала практика, не изменяет картину принципиально, и итоговый результат мало отличается от использования 10 UDP потоков.

          Поскольку тесты автоматизированные, то они состоят из итераций. UDP потоки на каждой итерации запускаются на 20 секунд, после чего мы снимаем итоговую суммарную статистику по скоростям, задержками и потерям пакетов, а также загрузку процессора маршрутизатора и записываем все значения в виде строчки файла типа CSV. Загрузка процессора снимается по SNMP самой IXIA каждые 5 секунд, для этого мы используем SNMP oid: .1.3.6.1.4.1.9.2.1.56.0 — загрузка CPU в среднем за за 5 секунд, в CSV файл записывается последнее из полученных по SNMP значений. Принцип поиска итоговой скорости следующий:
1) На первой итерации скорость передачи практически равна максимальной скорости на линии для данного размера фрейма TxRate = 99% Line rate (IXIA равномерно разделяет эту скорость по всем UDP потокам). Как правило, в этом случае мы имеем очень большой процент потерь, и скорость приёма RxRate значительно ниже скорости передачи. Это пристрелочная итерация.
2) Для следующей итераций мы в качестве TxRate выставляем значение равное RxRate + X Мбит/c. Получаем результаты и записываем их. Значение X будет определять точность теста, сначала мы брали это значение равным 10, затем сократили до 4.
3) Продолжаем итерации, но на каждой следующей итерации уменьшаем TxRate на X/2 Мбит/c до тех пор, пока процент потерянных пакетов не станет ниже нашего критерия.
4) Достигнув скорости, при которой отсутствуют потери, продолжаем итерации. Для каждой итерации TxRatei = A*TxRate(i-1). (Значение коэффициента A – также как и X определяет точность теста. Аналогично X мы сначала брали это число равным 0.95, затем увеличили до 0.97) Итерации продолжаются до тех пор, пока загрузка процессора за 5 секунд не станет ниже 75%.
Примечание: точность результатов при X=4, и A=0.97 будет равна 2 Мбит/c или 3% в зависимости от того, что будет больше. При необходимости скрипт позволяет увеличить точность, однако при этом увеличится и количество итераций.

          Мы можем провести тесты для любых размеров пакетов/кадров (вопрос лишь во времени и целесообразности). На данный момент времени мы тестировали при размерах кадров равных 100 байт; 400 байт; 1400 байт. Размер заголовков Ethernet кадров – 18 байт, тэгирование не используется. Такие размеры мы взяли не случайно: маленькие пакеты позволяют получить некоторые предельные характеристики (применимо, когда преобладает трафик подобного размера, например VoIP); кадры в 400 байт можно принять эквивалентными IMIX трафику и показывают средние значения производительности; кадры размеров 1400 байт – удобно использовать для оценки показателей максимальной производительности.
ВАЖНО: скорости в отчётах TxRate и RxRate, выраженные в Мбит/c – это скорости на линии с учётом заголовков канального уровня.

          Пример тестирования простой статической маршрутизации

          Базовая конфигурация маршрутизатора 1

Show »


# Для упрощения доступа на оборудование во время тестирования
aaa new-model
aaa authentication login default none
aaa authentication enable default none
!
# Отключаем ненужные функции
no ip source-route
no ip domain lookup

no ip http server
no ip http secure-server

# Для получения загрузки CPU за 5 секунд с помощью IXIA
snmp-server community public RO

# Настройка IP адресации на интерфейсах
interface GigabitEthernet0/0
ip address 10.2.1.1 255.255.255.0
no shut
!
interface GigabitEthernet0/1
ip address 192.168.2.1 255.255.255.0
no shut

# Настройка статических маршрутов для подсетей источника/получателя IXIA
ip route 172.25.1.0 255.255.255.0 10.2.1.2
ip route 172.25.2.0 255.255.255.0 192.168.2.2
ip route 10.2.2.0 255.255.255.0 192.168.2.2

          Таблица маршрутизации тестируемого маршрутизатора 1

Show »


Router#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override


Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.2.1.0/24 is directly connected, GigabitEthernet0/0
L 10.2.1.1/32 is directly connected, GigabitEthernet0/0
S 10.2.2.0/24 [1/0] via 192.168.2.2
172.25.0.0/24 is subnetted, 2 subnets
S 172.25.1.0 [1/0] via 10.2.1.2
S 172.25.2.0 [1/0] via 192.168.2.2
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, GigabitEthernet0/1
L 192.168.2.1/32 is directly connected, GigabitEthernet0/1

          Настройки для маршрутизатора 2 — аналогичны.

Таблица с результатами тестирования Cisco 1921 для статической маршрутизации:

Test_Table

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

Продолжение следует…

 

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

 

2 комментария “IXIA. Схемы и методология нагрузочного тестирования”

comment rss - Trackback

  1. Я бы добавил, что для каждого размера пакета «правильным» числом будет последняя строка, потому что именно здесь мы говорим о нормальной, а не близкой к предельной нагрузке. Т.е. рассчитывать, что маршрутизатор прокачает Х мбит/сек трафика, глядя на 100% загрузки CPU, очевидно, не правильно. Полная таблица позволяет провести экстраполяцию результатов и получить примерные значения пропускной способности, скажем, для CPU=50%

  2. rusnino:

    А как объяснить тот факт, что в некоторых строчках Rx(fps) оказался больше Tx(fps)? То же самое, применимо к Rx(Mbps) и Tx(Mbps)? Это видимо опечатки?

» Оставить комментарий

Вы должны войти чтобы прокомментировать.