Моніторимо Канлі зв'язку на маршрутизаторах HP MSR NG

    
— Знайомтесь! Аліса, це пудинг! Пудинг, це Аліса! Понесіть!…
Ну ось, вас тільки познайомили, а ти вже на нього з ножем!
© Льюїс Керролл. Аліса в країні чудес
 
Пройшов вже рік, відтоді як компанія HP оновила лінійку маршрутизаторів корпоративного класу HP MSR. Нові маршрутизатори так і назвали — маршрутизатори нового покоління або MSR NG. Це абсолютно нові пристрої з апаратної точки зору, що використовують багатоядерні процесори з вбудованим прискорювачем шифрування, шину PCIE 2.0 і помітно більший обсяг як оперативної, так і флеш пам'яті. Насамперед нова апаратна платформа дозволила отримати багаторазовий приріст продуктивності, який допоміг компанії HP обігнати багатьох іменитих "колег по цеху". Звичайно ж, для реалізації цієї продуктивності потурбувалися серйозним чином переробити і операційну систему, називається вона по колишньому HP Comware, а ось версія вже 7. З появою цієї ОС крім підвищення надійності та проізводітелньості з'явилося маса нових функцій, таких як: вдосконалена технологія створення динамічних VPN — HP ADVPN, підтримка отказоустойчивого IRF стекирования маршрутизаторів, вбудована система автоматизації EAA, міжмережевий екран з зонами і ще багато інших корисних в мережевому господарстві функцій.
Цією статтею ми починаємо знайомити читачів нашого блогу з маршрутизаторами HP MSR NG і новим функціоналом операційної системи HP Comware 7. Перша стаття з цього циклу, вона присвячена наприклад рішення распростанение завдання моніторингу каналів зв'язку за допомогою маршрутизатора HP MSR NG.
 
Отже, вирішуємо завдання моніторингу доступності каналу зв'язку за допомогою ICMP ехо-запитів, або, говорячи простою мовою, за допомогою "пінгів". При недоступності сервісу повідомляємо адміністратору про зміну стану всіма доступними засобами — відправляємо SNMP trap на систему управління, syslog повідомлення з довільним змістом на syslog сервер і пишемо електронного листа через ESMTP сервер. Інші дії, такі як перемикання на резервний канал і зміна конфігурації можна додати як сіль і цукор — за смаком. Конфігурацію можна обкатувати на HP Network Simulator , ми ж, для різноманітності, скористаємося віртуальним маршрутизатором HP VSR1000 , завантажити який можуть усі бажаючі. Маршрутизатор підтримує платформи віртуалізації VMware ESXi і Linux KVM, але, для наших цілей, його можна запустити і на VMware Workstation 10 версії і, навіть, на VMware Player. Вимоги до віртуальної машини:
 
     
  • Processor One vCPU (main frequency ≥ 2.0 GHz);
  •  
  • Memory 1 GB;
  •  
  • Hard disk One vHD, 8 GB;
  •  
  • Network interface card Two virtual NICs at least. Up to 16 virtual NICs are supported;
  •  
  • Virtual NIC types: E1000 (VMware ESXi and Linux KVM), VMXNET3 (VMware ESXi), VirtIO (Linux KVM), InteI 82599 VF (VMware ESXi and Linux KVM).
  •  
Вимоги, як ми бачимо, за сучасними мірками далеко не захмарні, що дозволить нам запустити пару маршрутизаторів для відпрацювання конфігурації прямо на робочому ноутбуці. У складі скаченного дистрибутива ми знайдемо три файли з розширеннями:
 
     
  • ". ipe" — ПО Comware 7 для апгрейда вже функціонуючого маршрутизатора;
  •  
  • ". iso" — образ для інсталяції ПЗ на віртуальну машину самостійно;
  •  
  • ". ova" — готовий образ віртуальної машини з уже встановленим HP VSR 1000.
  •  
Ми скористаємося готовим чином OVA і створимо у віртуальному середовищі следующии схему мережі: image
Процес інсталяції маршрутизатора HP VSR1000 на VMware Player вкрай простий і інтуїтивно зрозумілий.
Після інсталяції маршрутизаторів і налаштування мережевого оточення VMware згідно нашої схеми запускаємо віртуальні машини і виконуємо початкові налаштування, які дозволять отримати звичний доступ з термінальної програми по протоколу SSH. Як встановити HP VSR, створити стенд використовуючи ПО VMware Player і виконати попередні налаштування показано в ролику .
Тепер, отримавши звичний доступ по SSH, переходимо до вирішення нашого завдання. Нам знадобиться налаштувати дві функції — Network quality analyzer (або коротко NQA) і Embedded Automation Architecture (EAA).
Network quality analyzer (NQA) — функціонал, який дозволяє вимірювати параметри мережі передачі даних для різних типів додатків. Підтримується мониториг функціонування таких додатків:
 
     
  • ICMP echo;
  •  
  • DHCP;
  •  
  • DNS;
  •  
  • FTP;
  •  
  • HTTP;
  •  
  • UDP jitter;
  •  
  • SNMP;
  •  
  • TCP;
  •  
  • UDP echo;
  •  
  • Voice;
  •  
  • Path jitter;
  •  
  • DLSw.
  •  
Працює цей функціонал наступним чином: маршрутизатор-зонд, або NQA Client в термінах HP, формує пакет-запит і відправляє його на віддалене пристрій (NQA destination device), яке відповідає на запити зонда. Для функцій моніторингу пакетами TCP, UDP echo, UDP jitter і голосовими пакетами в ролі NQA відповідача обов'язково повинен виступати маршрутизатор HP (NQA Server), на інші типи запитів можуть відповідати і інші мережеві пристрої.
У нашому прикладі розглянемо роботу NQA в режимі тестування каналу за допомогою ICMP луна-запитів. Маршрутизатор VSR1000-1, що виконує моніторинг каналу, "пінг" заданий IP адреса (у нашому випадку HP VSR1000-2) і на основі отриманих відповідей робить висновок про рабоспособності каналу.
Маршрутизатор дозволяє завадать наступні параметри: image
Налаштування NQA зонда, який буде кожні 30 секунд відправляти 5 ICMP echo запосіли на IP адреса 192.168.1.2 з виставленим в значення "А0" полем IP ToS (DSCP 40), розміром 1024 байта кожен і чекати відповіді в перебігу 0,5 секунд на маршрутизаторі виглядає наступним чином:
 
[VSR1000-1] nqa entry icmp 1
[VSR1000-1-nqa-icmp-1] type icmp-echo
[VSR1000-1-nqa-icmp-1-icmp-echo]
[VSR1000-1-nqa-icmp-1-icmp-echo] description === Test1 ===
[VSR1000-1-nqa-icmp-1-icmp-echo] destination ip 192.168.1.2
[VSR1000-1-nqa-icmp-1-icmp-echo] frequency 30000
[VSR1000-1-nqa-icmp-1-icmp-echo] data-size 1024
[VSR1000-1-nqa-icmp-1-icmp-echo] tos 160
[VSR1000-1-nqa-icmp-1-icmp-echo] probe count 5
[VSR1000-1-nqa-icmp-1-icmp-echo] probe timeout 500
 
Далі нам необхідно задати реакцію маршрутизатора на результати тестування каналу зв'язку. У нашому прикладі будемо вважати відмовою каналу зв'язку послідовне неотримання трьох відповідей на відправлені "пинги". Тут же ми вирішимо першу з поставлених завдань, а саме змусимо маршрутизатор згенерувати SNPM trap як при перевищенні порога в 3 послідовно втрачених відповіді, так і при зниженні числа втрат нижче заданого значення:
 
[VSR1000-1-nqa-icmp-1-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 3 action-type trap-only
У нас вийшла наступна конфігурація NQA:
 
[VSR1000-1] display current-configuration configuration nqa
#
nqa entry icmp 1
 type icmp-echo
 data-size 1024
 description === Test1 ===
 destination ip 192.168.1.2
 frequency 30000
 probe count 5
 probe timeout 500
 reaction 1 checked-element probe-fail threshold-type consecutive 3 action-type trap-only
 source ip 192.168.1.1
 tos 160
#
Для того, щоб маршрутизатор міг відправити SNMP trap необхідно вказати версію протоколу SNMP, IP адреса станції управління та securityname:
 
[VSR1000-1] snmp-agent sys-info version v2c
[VSR1000-1] snmp-agent target-host trap address udp-domain 172.16.1.100 params securityname public v2c
 
Набудуємо SNMP community на читання, це буде потрібно нам для подальших дій, пов'язаних з пошуком об'єкта SNMP, що відповідає за даний запис NQA:
 
[VSR1000-1] snmp-agent community read simple public
 
Можна запускати наш зонд:
 
[VSR1000-1] nqa schedule icmp 1 start-time now lifetime forever
 
Тепер, при виявленні змін в стані каналу зв'язку маршрутизатор буде відправляти SNPM повідомлення на IP адреса 172.16.1.100.
Подивитися в живу процес налаштування можна пройшовши по посиланням .
Переходимо до вирішення другої частини поставленого завдання — змусимо наш прилад генерувати syslog повідомлення, яке дублює SNMP trap. Для цього ми будемо використовувати вбудовану систему автоматизації — HP EAA (Embedded Automation Architecture). Загальна архітектура EAA показана на малюнку: image
Цей функціонал дозволяє пристрою реєструвати різні події, такі як введення команди, поява заданого syslog повідомлення, установку нового модуля в маршрутизатор і безліч інших. На основі зареєстрованого події маршрутизатор дозволяє виконати різні дії:
 
     
  • виконати набір команд;
  •  
  • відправити syslog повідомлення;
  •  
  • виконати перемикання між основним і резервним керуючим модулями;
  •  
  • виконати перезавантаження маршрутизатора з / без збереженням конфігурації.
  •  
Для виконання цих дій може використовуватися як СLI скрипт, так і скрипт написаний на TCL версії 8.5.
Для генерації syslog повідомлень ми будемо використовувати два TCL скрипта. Перший буде реєструвати зміну SNMP OID соответсвующего NQA зонду зі стану "overThreshold (2)" у стан "belowThreshold (3)", що відповідає переходу каналу зв'язку з неробочого в робочий стан і відправляти syslog повідомлення про те, що наш канал доступний. Другий реєструватиме зворотну еволюцію NQA зонда, а саме перехід зі стану "belowThreshold (3)" у стан "overThreshold (2)" що відповідає переходу каналу зв'язку з робочого стану в неробочий і відправляти syslog повідомлення про те, що наш канал вийшов з ладу.
Першою проблемою, з якою стикається допитливий адміністратор на шляху до реалізації задуманого є, власне, пошук SNMP OID, що відповідає за стан налаштованого NQA. Для вирішення цього завдання нам буде потрібно бібліотека MIB, доступна для скачування за адресою MIBs_V7 , і будь MIB browser (я скористався безкоштовною версією Ireasoning MIB Browser Personal Edition ). Зі складу цієї бібліотеки завантажуємо в MIB browser MIB з назвою "hh3c-nqa.mib". У MIB браузері знаходимо в об'єкт "hh3cNqaReactCurrentStatus" і виконуємо команду "Get Subtree" попередньо вказавши IP адресу нашого маршрутизатора (172.16.1.1) і community ("public"). У відповідь ми отримали шуканий об'єкт, в моєму випадку це SNMP OID .1.3.6.1.4.1.25506.8.3.1.13.1.11.4.105.99.109.112.1.49.1.
Тепер в текствовом редакторі пишемо перший скрипт і називаємо його, наприклад, up.tcl. Цей скрипт буде раз в 10 секунд опитувати стан нашого SNMP OID, реєструвати зміна значення OID з "3" на "2" (що відповідає відновленню каналу зв'язку) і генерувати syslog з повідомленням виду "VSR1000-2 Dest IP 192.168.1.2 is available". На роботу відведемо скрипту 30 секунд:
 
:: Comware :: rtm :: event_register snmp oid 1.3.6.1.4.1.25506.8.3.1.13.1.11.4.105.99.109.112.1.49.1 monitor-obj get start-op eq start-val 3 restart-op eq restart- val 2 interval 10 running-time 30 user-role network-admin
:: Comware :: rtm :: action syslog priority 5 facility local4 msg «VSR1000-2 Dest IP 192.168.1.2 is available»
 
Аналогічним чином пишемо другий скрипт, який буде відслідковувати "падіння" каналу і видавати syslog виду "VSR1000-2 Dest IP 192.168.1.2 is unavailable":
 
:: Comware :: rtm :: event_register snmp oid 1.3.6.1.4.1.25506.8.3.1.13.1.11.4.105.99.109.112.1.49.1 monitor-obj get start-op eq start-val 2 restart-op eq restart- val 3 interval 10 running-time 30 user-role network-admin
:: Comware :: rtm :: action syslog priority 5 facility local4 msg «VSR1000-2 Dest IP 192.168.1.2 is unavailable»
 
Потім завантажуємо отримані файли "up.tcl" і "down.tcl" на флеш пам'ять машрутізатора і реєструємо їх:
 
[VSR1000-1] rtm tcl-policy up flash :/ up.tcl
[VSR1000-1] rtm tcl-policy down flash :/ down.tcl
 
Залишається тільки поставити в конфігурації маршрутизатора IP адреса syslog сервера:
 
[VSR1000-1] info-center loghost 172.16.1.100
 Ролик, що демонструє цю частину конфіга .
Ми навчили наш маршрутизатор на додаток до SNMP trap'у відправляти syslog повідомлення.
Преходимо до заключної частини нашої задачі — відправці email повідомлення через ESMTP сервер.
Для вирішення цього завдання скористаємося готовим скриптом, який можна скачати за адресою http://wiki.tcl.tk/417 . Зберігаємо його в файл sendmail.tcl і записуємо в кореневий каталог флеш пам'яті маршрутизатора. Скрипт описує процедуру, і вимагає визначення наступних змінних:
 
     
  • smtphost — IP адреса ESMTP сервера;
  •  
  • toList — адреси одержувачів e-mail;
  •  
  • from — адреса відправника e-mail;
  •  
  • subject — тема листа;
  •  
  • body — вміст листа;
  •  
  • {trace 0} — включення / виключення інформації для налагодження.
  •  
Частина змінних, а саме, адреса поштового сервера і одержувача повідомлень ми задамо в конфігараціі маршрутизатора:
 
[VSR1000-1] rtm environment smtphost 172.16.1.100
[VSR1000-1] rtm environment toList ADMIN@company.org
 
Решта змінні визначаємо в тілі наших скриптів:
 
variable from VSR1000-1@test.org
variable subject "VSR1000-2 availability"
variable body "VSR1000-2 Dest IP 192.168.1.2 is available"
 
Так само, в тіло скриптів up.tcl і down.tcl додаємо рядок, яка реєструє бібліотеку, що відповідає за відправку пошти:
 
source sendmail.tcl
 
І сходинку, яка викликає дану процедуру:
 
sendmail $ smtphost $ toList $ from $ subject $ body
 
Кому цікаво, дивимося відео цього процесу.
Ось власне і все, що було потрібно налаштувати.
Отримані в результаті конфігурації і скрипти можна сказати тут:
Конфігурація маршрутизатора HP VSR1000-1
Конфігурація маршрутизатора HP VSR1000-2
Скрипт up.tcl
Скрипт down.tcl
Скрипт sendmail.tcl
Дана стаття не претендує істину в останній інстанції, не закликає Раша ваші завдання саме так і скоріше є демонстрацією інструментарію, доступного для власників маршрутизаторів HP MSR NG. Сподіваюся, ці відомості допоможуть розробити нашим читачам власні конфігурації, вирішальні їх унікальні виробничі завдання.
У процесі виконання завдання використовувалися матеріали:
 HP VSR1000 Virtual Services Router Installation and Getting Started Guide
 HP VSR1000 Virtual Services Router Network Management and Monitoring Configuration Guide
R0202-HP VSR1000 Virtual Services Router Network Management and Monitoring Command Reference

    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.