RPM

Real-time performance monitoring (RPM) - это инструмент мониторинга производительности в режиме реального времени для оценки и анализа эффективности работы сети. Как правило, производительность сети оценивается на основе джиттера, задержки и потерь пакетов.

RPM позволяет маршрутизатору отслеживать такие показатели, как round-trip delays (задержки при прохождении пакета в обе стороны) и unanswered echo requests (эхо-запросы без ответа). Для этого RPM обменивается набором запросов зондов с другим IP хостом в сети. С помощью этих зондов можно собрать такие данные, как transit delay (транзитная задержка), jitter, round-trip time (RTT, суммарное время прохождения пакета в обе стороны), positive egress jitter, negative egress jitter, positive ingress jitter, negative ingress jitter, positive round-trip jitter, negative round-trip jitter. RPM может вычислить минимальное, максимальное, среднее, от пика до пика, стандартное отклонение, а также сумму по каждому из этих измерений. RPM зонды также могут использоваться для проверки пути между BGP соседями.

RPM в наиболее простой форме может быть описан как взаимосвязь клиента (источник), отсылающего запросы зондов, и сервера (узел назначения), отвечающего на них. Клиентское устройство посылает пакет удаленному серверу, который, в свою очередь, возвращает пакет с подтверждением отправителю. Тип и содержание запроса, передаваемые от клиента, конфигурируются пользователем. Запросы и ответы зонда происходят между определенными пользователем адресами источника и назначения. Служба RPM является процессом (rmopd), работающем на Routing Engine.

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

• Internet Control Message Protocol (ICMP) echo
• ICMP timestamp (временная метка)
• HTTP get (не доступно для BGP RPM сервиса)
• UDP echo
• TCP connection
• UDP timestamp

При этом ICMP-ping используется по умолчанию.

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

Типы временных меток

TIMESTAMP	Описание	Направление
T1	Source (Client) Query (Request) Out	Egress
T2	Destination (Server) Query (Request) In	Ingress
T3	Destination (Server) Reply (Response) Out	Egress
T4	Source (Client) Reply (Response) In	Ingress

В случае использования ICMP зондов, где сервером является не-Juniper оборудование, сервер будет отвечать RPM зонду без добавления временной метки, соответственно вычисляться будет только задержка RTT.

Основные элементы, необходимые для корректного функционирования сервиса RPM, включают:

• Timestamps (Временные метки)
• Структура RPM
• Конфигурация и отчет по результатам
• Интерфейс назначения

Timestamps

Временные метки необходимы для учета любых задержек в пакетной коммутации. Timestamps могут быть применены на клиенте или сервере, либо одновременно на клиенте и сервере. Все узлы в сети должны быть синхронизированы с общим точным источником времени (желательно уровня Stratum 3) посредством Network Time Protocol(NTP). Типы зондов, поддерживающих функциональность временных меток включают в себя:

• icmp-ping
• icmp-ping-timestamp
• udp-ping
• udp-ping-timestamp

Функциональность временных меток включает источник(клиент)- узел применения временной метки(Т1) к RPM пакетам с того момента, как они покидают узел. Узел назначения(сервер) использует метку времени(Т2), когда он принимает зонд, и временную метку(Т3), когда зонд покидает узел назначения обратно к источнику. Источник получает ответ и использует временную метку(T4). На основании этих меток, собранных с набора зондов вычисляются различные метрики. Например, время отклика(RTT) может быть вычислена как разность между отметками времени T1 и T4 минус разность T3 и Т2.

Timestamping может выполняться как аппаратными средствами. так и программно. Изначальные типы программного или классического timestamping выполнялись на запрашивающем Routing Engine посредством процесса rmopd во время отправки и получения RPM зондов. Однако использование единой операционной системы влияет на точность измерений.

Последующий тип timestamping выполняется аппаратными средствами и использует временные метки Т1-Т4 в полезной нагрузке RPM. Сервисный PIC на маршрутизаторах M Series Multiservice Edge Routers и T Series Core Routers, а также процесс fwdd на J Series Services Routers порождает поток временных меток в реальном времени.

Использование односторонней аппаратной временной метки (one-way-hardware-timestamp) позволяет вычислять метки на каждом направлении, Т1-Т2 или Т3-Т4. One-way timestamps работает только с аппаратными временными метками. Настройка односторонней аппаратной временной метки позволяет проводить такие односторонние измерения, как входная задержка, исходящая задержка, входной джиттер и исходящий джиттер. Каждая односторонняя задержка сверяется с соответствующей round-trip задержкой, и если она больше, то игнорируется.

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

                                                Формат RPM временной метки

Что такое зонды и тесты

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

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

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

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

Зонд может быть одного из типов, описанных в таблице ниже. Измерение RPM может состоять из нескольких тестов, каждый из которых содержит различные типы зондов, и заключается во взаимодействии между парой конкретных IP-адресов источника и назначения. Интервал между зондами и тестами, как и содержание порции данных зондов настраивается пользователем. Пользователь также может контролировать количество зондов, принадлежащих тесту. Алгоритм в рамках программного обеспечения определяет число зондов, отправляемых одновременно от источника к назначению. Каждому зонду может быть присвоен класс пересылки трафика, окрашенный определенным типом DiffServ code point (DSCP) в заголовке IP пакета. Пакеты зонда обрабатываются на основании класса трафика, к которому они принадлежат, когда используются в связке с логическим туннелем (lt) или sp интерфейсом в качестве интерфейса назначения. Предельные приемлемые уровни различных задержек могут быть заданы, так же, как и тревожные или аварийные триггеры, которые будут срабатывать при превышении этих показателей. SNMP traps должны быть включены для срабатывания сигнализации.

Типы зондов и их функции

ТИП ЗОНДА	ФУНКЦИЯ
udp-ping-timestamp	UDP timestamp запросы отправляются к адресу назначению с T1,T2,T3,T4 временными метками
udp-ping	UDP пакеты направляются к назначению. Поддерживается весь ряд аппаратных меток (T1-T4)
tcp-ping	TCP пакеты направляются к назначению. Аппаратные timestamps не поддерживаются
icmp-ping	ICMP запрос направляется к адресу назначения. Поддерживается весь ряд аппаратных меток (Т1-Т4)
icmp-ping-timestamp	ICMP timestamp запросы направляются к адресу назначения с T1,T2,T3,T4 временными метками
http-get (не доступно для BGP RPM)	HTTP get запросы направляются к целевому URL
http-metadata-get	HTTP get запрос для metadata к целевому URL

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

Конфигурация и представление результатов

RPM зонды могут быть настроены с ОС Junos CLI, SNMP и J-Web. Результаты могут быть сообщены через CLI, J-Web или SNMP. Кроме того, сторонние MIB-браузеры или приложения управления производительностью могут использоваться для получения данных RPM измерений и построения итоговых графиков.

Настройка RPM зондов

RPM зонды могут быть настроены через CLI, SNMP или J-Web. Настройка зондов и их параметров производится на уровне иерархии [edit services rpm]

owner owner { *идентификация владельца зонда и включение логического группирования тестов
       test test-name { *имя теста
            data-fill data; *содержание части данных ICMP-зондов; шестнадцатеричное значение в диапазоне от 1 до 800h
            data-size size; *размер (в байтах) части данных в ICMP-зондах
            destination-interface interface-name; *интерфейс на RPM клиенте; включает аппаратную временную метку на M Series,T Series, and EX3200 и EX4200 Ethernet коммутаторах.
            destination-port port; *TCP или UDP порт, к которому направлены зонды; Можно использовать 7(стандартный номер порта для TCP и UDP) или выбрать из диапазона 49152-65535
            dscp-code-point dscp-bits; *DSCP биты, соответствующие классу трафика в IP-заголовке. По умолчанию 000000.
            hardware-timestamp; *включение аппаратной временной метки сообщений RPM зонда на маршрутизаторе
            history-size size; *число хранящихся записей истории(0-255)
            moving-average-size number; *число образцов, используемых для скользящего среднего значения
            one-way-hardware-timestamp; *включение всех 4-х временных меток в пакете для того, чтобы можно было измерить одностороннюю характеристику передачи к целевому адресу зонда и обратно
            probe-count count; *указывает общее число зондов, отправленных для каждого теста (1-15)
            probe-interval seconds; *время ожидания (в секундах) между каждой передачей зонда (1-255)
            probe-type type; *тип зонда, отправляемый как часть теста (http-get,http-get-metadata,icmp-ping,icmp-ping-timestamp,tcp-ping,udp-ping)
            routing-instance instance-name; *routing-instance для пинга внутри vrf
            source-address address; *исходный адрес зонда(если не указано, то адрес исходящего интерфейса).
            target (url url | address address); *целевой адрес зонда
            test-interval interval; *время ожидания (в секундах) между тестами(0-86400)
            thresholds thresholds; *лимиты теста и зонда
            traps traps; генерирует системные прерывания SNMP при указанном превышении пороговых значений*
       }
}

Рекомендации по настройке временных меток (Timestamps) для RPM

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

• icmp-ping
• icmp-ping-timestamp
• udp-ping
• udp-ping-timestamp

Конфигурация на различных платформах осуществляется разными способами.

Timestamps на платформах M Series и T Series

Если маршрутизатор имеет Adaptive Services(AS) или MultiServices PIC, то можно включить временное маркирование RPM сообщений зондов. Временная метка применяется на RPM клиентском маршрутизаторе (тот, который порождает RPM зонды) и на RPM сервере (маршрутизатор, отвечающий RPM зондам) только для IPv4 трафика. Поддерживаются сервисы 2-го уровня на всех MultiServices PIC и сервисы 3-го уровня на AS и MultiServices PIC.

Для настройки двустороннего временного маркирования на платформах M Series и T Series включается параметр destination-interface на уровне иерархии [edit services rpm probe probe-owner test test-name]. Пример:

[edit]
services rpm probe probe-owner test test-name {
    destination-interface sp-fpc/pic/port.logical-unit;
}


RPM клиентский маршрутизатор определяется на логическом интерфейсе на AS PIC путем включения параметра rpm на уровне иерархии [edit interfaces interface-name unit logical-unit-number]. Пример:

[edit]
interfaces interface-name unit logical-unit-number {
    rpm client;
}


Логический интерфейс (unit 0) должен быть посвящен задачам RPM. Это требует конфигурации family inet и адресов с маской /32, как показано в примере ниже. Эта конфигурация также нуждается в других сервисах, таких как Network Address Translation (NAT) и stateful firewall.

При конфигурировании RPM timestamping на AS PIC нельзя настроить source-address на уровне иерархии [edit services rpm probe probe-name test test-name]. Для конфигурирования одностороннего timestamping нужно также включить параметр one-way-hardware-timestamp на уровне иерархии [edit services rpm probe probe-owner test testname]. Пример:

[edit]
services rpm probe probe-owner test test-name {
    one-way-hardware-timestamp;
}


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

Если RPM зонды настраиваются для services interface (sp-), необходимо анонсировать локальные маршруты определенным образом для следующих протоколов маршрутизации:

• Для OSPF анонс локального маршрута производится путем включения сервисного интерфейса (sp) в OSPF area. Для этого interface sp-fpc/pic/port прописывается на уровне [edit protocols ospf area area-number].
• Для BGP и IS-IS маршруты интерфейса экспортируются и создается политика, которая принимает локальный маршрут сервисного интерфейса. Для экспорта маршрутов интерфейса параметры point-to-point и lan включаются на уровне иерархии [edit routing-options interface-routes family inet export]. Для настройки политики экспорта, которая разрешает локальный маршрут сервисного интерфейса, нужно параметры protocol local, rib inet.0, route-filter sp-interface-ip-address/32 exact настроить на уровне [edit policy-options policy-statement policy-name term term-name from], а также включить действие accept на уровне иерархии [edit policy-options policy-statement policy-name term term-name then]. Для того, чтобы политика экспорта вступила в действие, необходимо её применить к BGP или IS-IS с параметром export policy-name на уровне [edit protocols protocol-name].

Маршрутизация пакетов зондов через AS или MultiServices PIC также позволяет фильтровать пакеты зондов для определенных очередей. В следующем примере показана конфигурация RPM и фильтр, который определяет очередность:

Конфигурация RPM клиента:

services rpm { 

probe p1 { 

test t1 { 

probe-type icmp-ping; 

target address 10.8.4.1; 

probe-count 10; probe-interval 10; 

test-interval 10; 

dscp-code-points af11; 

data-size 100; 

destination-interface sp-1/2/0.0; 

} 

} 

} 

firewall { 

filter f1 {                             #  определение фильтра

term t1 { 

from { 

dscp af11; 

}

then { 

forwarding-class assured-forwarding; 

}

}

} 

} 

interfaces sp-1/2/0 { 

unit 0 { 

rpm client; 

family inet { 

address 10.8.4.2/32; 

filter {            #  применение фильтра (f1) к входной очереди

input f1; 

}

}

} 

} 

Конфигурация сервера:

interfaces sp-1/2/0 { 

unit 0 { 

rpm server; 

family inet { 

address 10.8.4.1/32; 

}

} 

}   


Timestamps на сервисных маршрутизаторах J Series

На сервисных маршрутизаторах J Series временные метки применяются к forwarding process (fwdd-rt).

• для настройки двустороннего временного маркирования параметр hardware-timestamp включается на уровне иерархии [edit services rpm probe probe-owner test test-name]:

[edit]

test mad-udp-ping {

probe-type udp-ping;

target address 20.20.20.2;

probe-count 5;

test-interval 20;

destination-port 49161;

dscp-code-points af22;

destination-interface ge-0/0/15.0;

}

probe-type icmp-ping;

target address 20.20.20.2;

probe-count 10;

test-interval 30;

dscp-code-points af43;

destination-interface ge-0/0/15.0;

}

rpm {

client;***

}

family inet {

address 20.20.20.1/24;

}