Многие знают, что в 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 |
На этом, собственно, всё. Спасибо за внимание 🙂
Давненько не комментировал статьи на этом сайте 🙂
По поводу проб и тестов: проба может содержать несколько тестов, и если хотя бы один тест не провален — статус всей пробы будет pass. И если в одной политике указаны две пробы — заваленная хотя бы одна уже приведет к fail’у и указанному действию. Это бывает полезно, если укажешь 8.8.8.8, а гугл накроется. Выгоднее мониторить две географически разные точки.
Juniper позволяет мониторить не только наличие отсутствия пинга, но и джиттер. Если у вас телефония — это намного более полезно.
Ну и возврат в предыдущее состояние — не всегда полезен, для этого есть опция no-preempt