
- •Засоби аналізу та управління мережами методичні вказівки
- •1.1Основи роботи з PySnmp
- •1.2Керування архітектурою snmp
- •1.2.1PySnmp архітектура
- •1.3Стандартні snmp додатки (Синхронні додатки)
- •1.3.1Генератор синхронних команд
- •1.3.2Синхронний оригінатор повідомлень
- •1.4Стандартні snmp додатки (Асинхронні додатки)
- •1.4.1Асинхронний генератор команд
- •1.4.2Асинхронний оригінатор повідомлення
- •1.4.3Конфігурація безпеки
- •1.4.4Конфігурація транспортування
- •1.5.1Managed Objects імена і значення
- •1.5.2Managed Objects значення
- •1.6.1Модель даних для керованих об'єктів
- •1.7Приклад PySnmp скриптів
- •1.8NativeApi для стандартних додатків snmPv3
- •1.9Низький рівень api для операцій протоколу snmPv1/v2c
- •1.10Подальший розвиток
- •2.1Встановлення
- •2.2Використання
- •2.3Структура
- •3.1Основні особливості модуля:
- •3.2Елементи модуля
- •3.3Переваги і недоліки
- •4.1Особливості
- •4.2Опис “NetSnmp” модуля
- •4.3Використання Net-snmp і iPython
- •4.3.1Встановлення та налаштування Net-snmp
- •4.3.2Написання коду
- •4.4Переваги і недоліки
- •Засоби аналізу та управління мережами методичні вказівки
1.4.2Асинхронний оригінатор повідомлення
Додаток оригінатор повідомлень реалізується в рамках одного класу:
Клас AsynNotificationOriginator ([ snmpContext ])
Створює асинхронний SNMP об'єкт оригінатора повідомлень.
Єдиний метод класу AsynNotificationOriginator, аналогічний описаному в NotificationOriginator класу за винятком того, що асинхронний інтерфейс використовує функцію зворотного виклику для підтвердження доставки після підтвердження повідомлення.
sendNotification ( authData , transportTarget , NotifyType , NotificationType , varBinds , (cbFun , cbCtx ))
Підготовка SNMP TRAP або INFORM повідомлення.
Повертає sendRequestHandle значення.
CbFun параметр є посиланням на викликуваний об'єкт (наприклад, функції Python), який приймає наступні параметри:
cbFun ( sendRequestHandle , errorIndication , cbCtx )
Де sendRequestHandle , errorIndication і cbCtx параметри мають той же зміст, що й у функції зворотного виклику в AsynCommandGenerator.getCmd методі.
CbCtx параметр має той же зміст, що і в AsynCommandGenerator.getCmd методі.
NotifyType , NotificationType і varBinds параметри мають той же зміст, що і вNotificationOriginator.sendNotification методі за винятком того, що тут він передається в якості кортежу.
SendNotification метод повертає унікальний sendRequestHandle - ціле значення, яке використовується для узгодження подальших відповідей підтвердження доставки в довільних повідомленнях.
Після одного чи декількох запитів,які були виклакані за одним або кількома з перерахованих вище методів, повинен бути викликаний TransportDispatcher. Це можна зробити застосувавши:
asynNotificationOriginator.snmpEngine.transportDispatcher.runDispatcher ()
Де asynNotificationOriginator є AsynNotificationOriginator екземпляром класу.
RunDispatcher () метод обривається, коли немає очікуваних запитів, які залишились для запуску додатків.
Наступний код відправляє кілька одночасних SNMP INFORM повідомлень декільком менеджерам. Перевірка справжності інформації, використовуваної в цьому прикладі є однаковим для всіх цілей.
Використання SNMP v2c
public SNMPv2
IPv4/UDP
прослуховування менеджерів на 127.0.0.1, 127.0.0.2, 127.0.0.3 (порт 162)
from pysnmp.entity.rfc3413.oneliner import ntforg
from pysnmp.proto import rfc1902
def cbFun(sendRequestHandle, errorIndication, cbCtx):
if errorIndication:
print(errorIndication)
else:
print('INFORM %s delivered' % sendRequestHandle)
ntfOrg = ntforg.AsynNotificationOriginator()
for target in ( ntforg.UdpTransportTarget(('127.0.0.1', 162)),
ntforg.UdpTransportTarget(('127.0.0.2', 162)),
ntforg.UdpTransportTarget(('127.0.0.3', 162)) ):
ntfOrg.sendNotification(
ntforg.CommunityData('public'),
target,
'inform',
ntforg.MibVariable('SNMPv2-MIB', 'coldStart'),
( ('1.3.6.1.2.1.1.5.0', rfc1902.OctetString('system name')), ),
(cbFun, None)
)
ntfOrg.snmpEngine.transportDispatcher.runDispatcher()
Наведений вище сценарій завершується, як і всі запити, або виконуються або завершуться по тайм-ауту.