Мониторинг с помощью RPM probe в Juniper
Многие знают, что в Cisco есть такая удобная штука, как IP SLA. Она позволяет прямо с устройства запускать различные тесты (icmp, tcp, udp), и на основании их совершать какие-то действия – например, переключать роуты.
Как использовать IP SLA для переключения каналов на роутере, можно почитать на замечательном сайте LinkMeUp (кстати, рекомендую весь цикл “Сети для самых маленьких”, узнаете много нового).
Ну а мы будем настраивать аналог IP SLA в Juniper, и называется он RPM (Realtime Perfomance Monitoring)
1. Что есть что
У нас есть пробы и тесты.
Проба – это, собственно, метрика, которую мы будем снимать. ICMP, UDP и т.д. Проба посылается на удалённый хост и отправляет ответ. Разумеется, если мы проверяем не просто ICMP, а udp/tcp-порт, то на удалённом хосте должен быть настроен респондер – причём вовсе не обязательно это должен быть такой же Juniper, может быть и обычный веб-сервер, если мы проверяем http url.
Поддерживаемые типы проб:
- HTTP GET request at a target URL
- HTTP GET request for metadata at a target URL
- ICMP echo request to a target address (the default)
- ICMP timestamp request to a target address
- UDP ping packets to a target device
- UDP timestamp requests to a target address
- TCP ping packets to a target device
Тест – это проба, запущенная в нужном количестве с нужным интервалом и параметрами (типа source port или next-hop). По каждому тесту можно посмотреть результат и статистику.
Давайте уже что-нибудь запустим
Настройка RPM довольно простая. Например, вот так выглядит простой icmp-тест
[cc]
set services rpm probe BRANCH test ICMP-PROBE probe-type icmp-ping
set services rpm probe BRANCH test ICMP-PROBE target address 172.27.1.17
set services rpm probe BRANCH test ICMP-PROBE probe-count 5
set services rpm probe BRANCH test ICMP-PROBE probe-interval 5
set services rpm probe BRANCH test ICMP-PROBE test-interval 5
set services rpm probe BRANCH test ICMP-PROBE thresholds successive-loss 5
set services rpm probe BRANCH test ICMP-PROBE destination-interface st0.4
[/cc]
“Как же так?” – спросите вы. Ведь мы только что договорились, что проба – это часть теста, а тут получается наоборот. Я не знаю, чем руководствовались разработчики JunOS, но в данном случае после probe идёт имя PROBE_OWNER – т.е. например роутер в филиале, к которому запускаются несколько тестов, или клиент, которого мы хотим мониторить. Немного путано, но так вот есть.
Параметры теста можно посмотреть в документации (там почти два десятка параметров). Также в этой же ветке (services rpm) можно настроить ответную часть пробы.
Что в результате?
Смотреть статистику по пробам можно вот так (можно все тесты указанного OWNER, можно только выбранного теста):
[cc]
root@srx340-01> show services rpm probe-results owner BRANCH
Owner: BRANCH, Test: ICMP-PROBE
Target address: 172.27.1.17, Probe type: icmp-ping
Destination interface name: st0.4
Test size: 5 probes
Probe results:
Response received, Thu Jan 11 08:38:38 2018, No hardware timestamps
Rtt: 12362 usec, Round trip jitter: -1450 usec, Round trip interarrival jitter: 1797 usec
Results over current test:
Probes sent: 5, Probes received: 5, Loss percentage: 0.000000
Measurement: Round trip time
Samples: 5, Minimum: 12362 usec, Maximum: 13886 usec, Average: 12975 usec, Peak to peak: 1524 usec, Stddev: 714 usec, Sum: 64876 usec
Measurement: Positive round trip jitter
Samples: 2, Minimum: 1426 usec, Maximum: 1456 usec, Average: 1441 usec, Peak to peak: 30 usec, Stddev: 15 usec, Sum: 2882 usec
Measurement: Negative round trip jitter
Samples: 3, Minimum: 436 usec, Maximum: 1500 usec, Average: 1129 usec, Peak to peak: 1064 usec, Stddev: 490 usec, Sum: 3386 usec
Results over last test:
Probes sent: 5, Probes received: 5, Loss percentage: 0.000000
Test completed on Thu Jan 11 08:38:38 2018
Measurement: Round trip time
Samples: 5, Minimum: 12362 usec, Maximum: 13886 usec, Average: 12975 usec, Peak to peak: 1524 usec, Stddev: 714 usec, Sum: 64876 usec
Measurement: Positive round trip jitter
Samples: 2, Minimum: 1426 usec, Maximum: 1456 usec, Average: 1441 usec, Peak to peak: 30 usec, Stddev: 15 usec, Sum: 2882 usec
Measurement: Negative round trip jitter
Samples: 3, Minimum: 436 usec, Maximum: 1500 usec, Average: 1129 usec, Peak to peak: 1064 usec, Stddev: 490 usec, Sum: 3386 usec
Results over all tests:
Probes sent: 981160, Probes received: 980587, Loss percentage: 0.058400
Measurement: Round trip time
Samples: 980587, Minimum: 9317 usec, Maximum: 994921 usec, Average: 14290 usec, Peak to peak: 985604 usec, Stddev: 10607 usec, Sum: 14012472325 usec
Measurement: Positive round trip jitter
Samples: 491354, Minimum: 0 usec, Maximum: 983440 usec, Average: 4496 usec, Peak to peak: 983440 usec, Stddev: 11249 usec, Sum: 2209222966 usec
Measurement: Negative round trip jitter
Samples: 489232, Minimum: 1 usec, Maximum: 983726 usec, Average: 4516 usec, Peak to peak: 983725 usec, Stddev: 11274 usec, Sum: 2209221859 usec
[/cc]
А какой с этого прок?
IP SLA хорош тем, что позволяет на основе результатов проб выполнять различные действия – в т.ч. включать или выключать маршруты. В Juniper тоже есть такая функция, называется IP monitoring.
Настраивается вот так:
[cc]
set services rpm probe BRANCH test ICMP-PROBE probe-type icmp-ping
set services rpm probe BRANCH test ICMP-PROBE target address 8.8.8.8
set services rpm probe BRANCH test ICMP-PROBE probe-count 5
set services rpm probe BRANCH test ICMP-PROBE probe-interval 5
set services rpm probe BRANCH test ICMP-PROBE test-interval 5
set services rpm probe BRANCH test ICMP-PROBE thresholds successive-loss 5
set services rpm probe BRANCH test ICMP-PROBE next-hop 192.168.1.1
set services ip-monitoring policy ISP-CHECK match rpm-probe BRANCH
set services ip-monitoring policy ISP-CHECK then preferred-route route 0.0.0.0/0 next-hop 192.168.2.1
[/cc]
Т.е. если группа тестов возвращает fail, то происходит переключение. Как только проба восстанавливается, возвращается и “нормальный” маршрут.
Выглядеть это будет примерно так:
[cc]
root@srx340-01> show services ip-monitoring status
Policy – ISP-CHECK (Status: PASS)
RPM Probes:
Probe name Test Name Address Status
———————- ————— —————- ———
BRANCH ICMP-PROBE 8.8.8.8 PASS
Route-Action:
route-instance route next-hop state
—————– —————– —————- ————-
inet.0 0.0.0.0/0 192.168.2.1 NOT-APPLIED
[/cc]
Посмотреть последние переключения:
[cc]root@srx340-01> show services rpm history-results
Owner, Test Probe received Round trip time
BRANCH, ICMP-PROBE Mon Jan 15 14:30:04 2018 1753 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:06 2018 7318 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:07 2018 1891 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:09 2018 7575 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:11 2018 1695 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:13 2018 Internal error
BRANCH, ICMP-PROBE Mon Jan 15 14:30:15 2018 Internal error
BRANCH, ICMP-PROBE Mon Jan 15 14:30:18 2018 Internal error
BRANCH, ICMP-PROBE Mon Jan 15 14:30:20 2018 Internal error
BRANCH, ICMP-PROBE Mon Jan 15 14:30:22 2018 Internal error
[/cc]
На этом, собственно, всё. Спасибо за внимание 🙂
Давненько не комментировал статьи на этом сайте 🙂
По поводу проб и тестов: проба может содержать несколько тестов, и если хотя бы один тест не провален – статус всей пробы будет pass. И если в одной политике указаны две пробы – заваленная хотя бы одна уже приведет к fail’у и указанному действию. Это бывает полезно, если укажешь 8.8.8.8, а гугл накроется. Выгоднее мониторить две географически разные точки.
Juniper позволяет мониторить не только наличие отсутствия пинга, но и джиттер. Если у вас телефония – это намного более полезно.
Ну и возврат в предыдущее состояние – не всегда полезен, для этого есть опция no-preempt