Skip to content

Мониторинг с помощью 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-тест

1
2
3
4
5
6
7
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

«Как же так?» — спросите вы. Ведь мы только что договорились, что проба — это часть теста, а тут получается наоборот. Я не знаю, чем руководствовались разработчики JunOS, но в данном случае после probe идёт имя PROBE_OWNER — т.е. например роутер в филиале, к которому запускаются несколько тестов, или клиент, которого мы хотим мониторить. Немного путано, но так вот есть.

Параметры теста можно посмотреть в документации (там почти два десятка параметров). Также в этой же ветке (services rpm) можно настроить ответную часть пробы.

Что в результате?

Смотреть статистику по пробам можно вот так (можно все тесты указанного OWNER, можно только выбранного теста):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
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

А какой с этого прок?

IP SLA хорош тем, что позволяет на основе результатов проб выполнять различные действия — в т.ч. включать или выключать маршруты. В Juniper тоже есть такая функция, называется IP monitoring.
Настраивается вот так:

1
2
3
4
5
6
7
8
9
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

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

Выглядеть это будет примерно так:

1
2
3
4
5
6
7
8
9
10
11
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

Посмотреть последние переключения:

1
2
3
4
5
6
7
8
9
10
11
12
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

На этом, собственно, всё. Спасибо за внимание 🙂

Be First to Comment

Добавить комментарий

%d такие блоггеры, как: