Показаны сообщения с ярлыком полезные команды. Показать все сообщения
Показаны сообщения с ярлыком полезные команды. Показать все сообщения

вторник, 23 ноября 2021 г.

Несколько bash комманд для почты, использования диска, отслеживания файлов

 Поиск писем,отравителей и т.д. по имени (домена/отправителя/получателя): 

bash#mf="/var/log/mail.info" && for n in `zgrep -i  zabbix-spd \$mf |  awk '{split($0,a," "); print a[6]}' | uniq` ;  do zgrep  "$n" $mf ; done 


Постоянный контроль размера файлов в каталоге:

bash#watch "ls -al /tmp/psqlodbc_zabbix126* | awk '{ print \$5 }'"

Обнуление файлов (можно по крону), от которых нельзя избавиться удалением (если их держит процесс, и при формальном удалении они продолжают занимать место на диске):

bash#for f in /tmp/psqlodbc_zabbix*.log; do echo "" > "$f"; done


Постоянное отслеживание новых записей в файле по паттерну и исполнение комманд с выбранным содержимым из найденной, по паттерну, строки (?проверить передачу переменных в curl):

bash#tail -F /var/log/mail.info | grep -E --line-buffered zabbix-spd\|dinoc | while read line; do echo -e "test: ${line}" | awk '{print $8}' |  xargs -I{} alert.sh {} ; done

Поиск по 2-м паттернам:

grep -E -i pattern_first\|second_pattern


пятница, 14 февраля 2020 г.

Троблешутинг Cisco ASA

При очередном обновлении Cisco ASA возникла неприятная ситуация, когда трафик почему-то пошел не в свои интерфейсы, на которые были статические маршруты, естественно возник асимметричный трафик  и он стал отбрасываться. Изначально переход был с релиза 8.4(1) на 9.0(3) и затем на 9.8(4)-15. при переходе с 8.4(1)  конфигурация была автоматически адаптирована промежуточным релизом 9.0(3) и на нем работала предсказуемо. При обновлении secondary ноды c 9.0(3) до 9.8(4)-15 проблем не было, и когда роль активной передали на secondary ноду, тоже всё работало нормально штатно, но когда обновили master ноду c 9.0(3) до 9.8(4)-15 и сделали активной, то трафик перестал ходить согласно таблицы маршрутизации, что привело к тому, что почти весь трафик стал дропаться. Выглядит это примерно так:



дело оказалось, что в каком-то релизе между 9.0(3) и 9.8(4)-15  Cisco поменяла логику определения выходного интерфейса при использовании  NAT и правило вида "nat(any, outside)...." стало отправлять трафик на OUTSIDE интерфейс, не зависимо от таблицы маршрутизации, т.е. route-lookup для NAT раньше был по умолчанию для правил NAT (хотя его можно было и указать явно в конфигурации). При указании этой опции на 9.8(4)-15 трафик пошел согласно таблицы статической маршрутизации.
Для отладки Cisco ASA можно использовать следующие команды:

создадим буфер для захвата трафика между определёнными IP:

cap capin trace interface management match ip host 10.0.19.49 host 10.129.190.3

cap capout trace interface DMZ-18 match ip host 10.129.190.3 host 10.0.19.49

cap asp type asp-drop all

Смотрим капчи:
ciscoasa/admin# show cap
capture capin type raw-data interface management [Capturing - 2250 bytes]
  match icmp host 10.0.19.49 host 10.129.190.3
capture capout type raw-data interface DMZ-18 [Capturing - 2820 bytes]
  match icmp host 10.0.19.49 host 10.129.190.3
capture asp type asp-drop all [Capturing - 534 bytes]
ciscoasa/admin# show cap asp

6 packets captured

   1: 14:46:01.645535       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop

   2: 14:46:03.645535       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop

   3: 14:46:03.765997       802.1Q vlan#58 P7 10.129.190.4.5353 > 224.0.0.251.5353:  udp 320 Drop-reason: (acl-drop) Flow is denied by configured rule

   4: 14:46:04.895354       0.0.0.0.68 > 255.255.255.255.67:  udp 292 Drop-reason: (acl-drop) Flow is denied by configured rule

   5: 14:46:05.645504       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop

   6: 14:46:07.645489       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop


ciscoasa/admin# show cap capout

8 packets captured

   1: 14:46:46.298431       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   2: 14:46:46.298980       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
   3: 14:46:51.298904       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   4: 14:46:51.299545       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
   5: 14:46:56.302352       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   6: 14:46:56.303008       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
   7: 14:47:01.301757       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   8: 14:47:01.302398       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
8 packets shown


ciscoasa/admin# show cap capout trace packet-number 2

12 packets captured

   2: 14:46:46.298980       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
NAT divert to egress interface outside
Untranslate 10.0.19.49/1 to 10.0.19.49/1

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group global_access global
access-list global_access extended permit icmp any4 any4 log warnings
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
Static translate 10.129.190.3/0 to 10.129.190.3/0

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:

Phase: 10
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 34202383, packet dispatched to next module

Phase: 12
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
NAT divert to egress interface outside
Untranslate 10.0.19.49/1 to 10.0.19.49/1

Phase: 13
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group global_access global
access-list global_access extended permit icmp any4 any4 log warnings
Additional Information:

Phase: 14
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
Static translate 10.129.190.3/0 to 10.129.190.3/0

Phase: 15
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 16
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 17
Type: SUBOPTIMAL-LOOKUP
Subtype: suboptimal next-hop
Result: ALLOW
Config:
Additional Information:
ifc selected is not same as preferred ifc
Doing route lookup again on ifc  outside

Phase: 18
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.0.1.32 using egress ifc  outside

Result:
input-interface: DMZ-18
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

1 packet shown

На релизе 9.0(3) trace  выглядит так:


ciscoasa/admin# cap capin trace interface management match ip host 10.0.19.49  host 10.129.128.4
ciscoasa/admin# show capture capin

4 packets captured

   1: 10:27:40.850786       10.0.19.49 > 10.129.128.4: icmp: echo request
   2: 10:27:40.851274       10.129.128.4 > 10.0.19.49: icmp: echo reply
   3: 10:27:41.866150       10.0.19.49 > 10.129.128.4: icmp: echo request
   4: 10:27:41.866623       10.129.128.4 > 10.0.19.49: icmp: echo reply
4 packets shown
ciscoasa/admin# show capture capin trace packet-number 1

26 packets captured

   1: 10:27:40.850786       10.0.19.49 > 10.129.128.4: icmp: echo request
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 1846, using existing flow

Result:
Action: allow


1 packet shown

Ссылка на Cisco:
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118097-configure-asa-00.html






среда, 16 октября 2019 г.

Простая обработка простого вывода: grep, awk, sort.

Иногда нужно понять что и как работает на множестве устройств, но заходить для этого на каждое устройства нет смысла если есть общее место хранения файлов конфигурации и последняя конфигурация сохраняется в этом месте автоматически. Для поиска нужной строки можно запустить поиск по содержимому в каталоге с файлами сохраненных конфигураций.
Т.к.  сохраняются файлы и предыдущих версий конфигурации, то  более новые помечаются добавлением номера версии "-ХХ" и если просто запустить grep <pattern>, то будет множество строк с одинаковыми названиями устройств, отличающихся только последними 2-3 знаками. Задача: найти файлы, отрезать индексы номера версий в названии, и выдать по одной уникальной строке на одно устройство. Решение примерно такое:
1) ищем подходящий паттерн (grep), подаём его на вход (awk), где указываем разделитель полей ((-F ":"), если нет то "пробел"), указываем в awk  чтобы вывел первую (или другую) Часть (относительно разделителя), но изменённую  substr, аргументом которой будет:
часть строки ($1),  далее номер  символа  для начала вывода в этой Части, и номер последнего символа в Части, длину которой определяем динамически оператором  length($1) и от которой отрезаем номер версии файла конфигурации 4  символа (надо подбирать, т.к. это д.б. с учетом сдвинутого ранее на 2 вывода Части). После этого подадим на вход команде sort -u для исключения одинаковых названий (без номера версий названия всех файлов конфигурации для одного узла будут одинаковы, и будет много одинаковых строк).

grep  "^interface Vlan5" ./* | awk -F ":" '{print substr($1,3,length($1)-4)}' | sort -u > vl5

Этот приём можно использовать когда название файла конфигурации можно ассоциировать с определённым узлом и тогда будет выведен столбец с названиями узлов, где имеется требуемая строка в конфигурации.

после grep:
./zld-lnn32-do-0:interface Vlan5
./zld-lnn32-do-1:interface Vlan5
./zld-lnn32-do-2:interface Vlan5

после  awk:
zld-lnn32-do
zld-lnn32-do
zld-lnn32-do

после sort:
zld-lnn32-do


пятница, 19 октября 2018 г.

Редкий случай relay на postfix

В один прекрасный момент заметил, что MTA на входящую почту  (только) попал в список RBL (sorbs). Проверять удобно на:

http://www.anti-abuse.org/multi-rbl-check-results/?host=IP-ADDRESS_MTA

 Данный сервер был правильно настроен на запрет relay, и работал много лет, проходил все тесты:

http://www.aupads.org/cgi-bin/test-relay.cgi?host_to_test=IP_ADDRESS_MTA

ещё:

https://mxtoolbox.com/SuperTool.aspx?action=smtp:IP_ADDRESS_MTA&run=toolpage#

И при этом у него не было роли отправлять почту, и он её не получал для отправки.

Просмотрел логи и заметил, что мой MTA буквально атакует bounce сообщениями определенный домен. Почистил очередь полезной командой (в письмах был домен жертва с именем ...babyv...):
grep -l -r "babyv" |  xargs rm
Затем в  master.cf внес изменения:
#bounce    unix  -       -       n       -       0       bounce
bounce    unix  -       -       n       -       0       discard
#defer     unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       discard
#trace     unix  -       -       n       -       0       bounce
trace     unix  -       -       n       -       0       discard

таким образом проблема решилась.




пятница, 14 сентября 2018 г.

Расширение размера диска на Ubuntu

Так получилось, что нарезали мне 100GB виртуалку не пустую, а из древнего шаблона, в котором изначально размер диска был 27GB. Вывод команды df -h был следующий:

Filesystem                1K-blocks     Used Available Use% Mounted on
udev                        1003072        0   1003072   0% /dev
tmpfs                        204812    13604    191208   7% /run
/dev/mapper/US16--vg-root  28269296 19417032   7502520  73% /
tmpfs                       1024052        0   1024052   0% /dev/shm
tmpfs                          5120        0      5120   0% /run/lock
tmpfs                       1024052        0   1024052   0% /sys/fs/cgroup
/dev/sda1                    482922   111019    346969  25% /boot
tmpfs                        204812        0    204812   0% /run/user/0


И вывод lvdisplay:

  --- Logical volume ---
  LV Path                /dev/US16-vg/root
  LV Name                root
  VG Name                US16-vg
  LV UUID                af1M0G-A0zc-fcGN-JsyM-ETuc-DOTW-YhH771
  LV Write Access        read/write
  LV Creation host, time US16, 2016-08-02 10:06:50 +0300
  LV Status              available
  # open                 1
  LV Size                <27,52 GiB
  Current LE             7044
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

Можно расширить без перезагрузки виртуальной машины, для этого (после расширения диска в конфигурации хоста в гипервизоре) выпоним команду сканирования жесткого диска:

 echo 1 > /sys/block/sda/device/rescan


дальше выполняем команду:

parted
p
(затем команду p)

Вывод: parted  (p)

GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  512MB   511MB   primary   ext2         boot
 2      513MB   21,5GB  21,0GB  extended
 5      513MB   21,5GB  21,0GB  logical                lvm

Необходимо увеличить размер видимый ОС (21,5GB) до реального (107GB)
надо запомнить всё выделено зеленым и вставлять как параметры при выполнеии следующих команд:

Видно что существует extended партиция и в ней размещен логический диск
Сначала увеличим размер  extended партиции где 2 и 5 номера разделов, а 107G из отмеченных зеленым параметров, полученных ранее:

parted
(parted)  resizepart 2
End?  [21,5GB]? 107GB

(parted)  resizepart 5
End?  [21,5GB]? 107GB
(parted) quit

Затем выполняем (только для logical диска):

 pvresize  /dev/sda5

Вывод:  Physical volume "/dev/sda5" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

Запустим на этом этапе:

 df -h

Вывод: 
Filesystem                 Size  Used Avail Use% Mounted on
udev                       980M     0  980M   0% /dev
tmpfs                      201M   16M  185M   8% /run
/dev/mapper/US16--vg-root   27G   19G  7,1G  73% /
tmpfs                     1001M     0 1001M   0% /dev/shm
tmpfs                      5,0M     0  5,0M   0% /run/lock
tmpfs                     1001M     0 1001M   0% /sys/fs/cgroup
/dev/sda1                  472M  109M  339M  25% /boot
tmpfs                      201M     0  201M   0% /run/user/0

Запусти команду ("/dev/mapper/US16--vg-root"  берем из  отмеченного зеленым, ранее):

 lvextend -r -l +100%FREE /dev/mapper/US16--vg-root

Вывод команды: 
  Size of logical volume US16-vg/root changed from <27,52 GiB (7044 extents) to <107,17 GiB (27435 extents).
  Logical volume US16-vg/root successfully resized.
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/mapper/US16--vg-root is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 7
The filesystem on /dev/mapper/US16--vg-root is now 28093440 (4k) blocks long.

Запустим снова:

 df -h
Filesystem                 Size  Used Avail Use% Mounted on
udev                       980M     0  980M   0% /dev
tmpfs                      201M   16M  185M   8% /run
/dev/mapper/US16--vg-root  106G   19G   83G  19% /
tmpfs                     1001M     0 1001M   0% /dev/shm
tmpfs                      5,0M     0  5,0M   0% /run/lock
tmpfs                     1001M     0 1001M   0% /sys/fs/cgroup
/dev/sda1                  472M  109M  339M  25% /boot
tmpfs                      201M     0  201M   0% /run/user/0

ОС увидела дополнительное место.
Перед началом каких-либо действий с дисковым пространством обязательно надо сделать snapshot виртуальной машины.







Установка Zabbix на Ubuntu

Появилась необходимость развернуть новый Zabbix под отдельный сектор мониторинга.
Т.к. прежний zabbix ставил давно и уже не помню тонкостей, решил оформить пост об актуальном процессе инсталляции.
Решаемые задачи:
1) Обновление ОС.
2) Установка необходимых компонентов ПО (mysql, apache, snmp, traceroute, nmap и т.д.)
3) Конфигурирование  mysql
4) Конфигурирование  apache
5) Конфигурирование  zabbix (zabbix.conf, глобальная автоинвентаризация, )
6) Составление списка хостов для мониторинга (nmap)
7) Настройка профилей автообнаружения (autodiscovery)
8) Настройка и запуск автообнаружения.

1.
Обновляем ubuntu по предыдущему сообщению. Дополнительно пропишем в файле
/etc/hosts названия хоста на которой будем ставить zabbix (в моем случае hostname машины был "zabbix")

127.0.0.1 zabbix
"your lan ip" zabbix

2.
Ставим утилиты snmp:

apt-get install snmp snmp-mibs-downloader

В файле /etc/snmp/snmp.conf
комментируем секцию "mibs :" (добавляем перед ней "#"):

# mibs :

запускаем скачивание mibs

sudo download-mibs
-------------------
Так получилось, что дистрибутив zabbix оказался с включенным в него mysql, я решил ставить в расчете, что mysql будет полностью изначально подготовлен для связки с zabbix (но это не так). Поэтому можно ставить mysql как обычно, если в zabbix не включает mysql:

sudo apt install mysql-server mysql-client

ввести пароль пользователя mysql "root", если спросит при инсталляции, или поставить его позже.
----------------
Если apache не стоит, то ставим (у меня уже стоял)

sudo apt install apache2
-------------------
Качаем дистрибутив zabbix:

wget https://repo.zabbix.com/zabbix/3.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_3.4-1+bionic_all.deb

dpkg -i zabbix-release_3.4-1+bionic_all.deb

apt update

apt install zabbix-server-mysql zabbix-frontend-php zabbix-agent
----------------
ставим остальные утилиты:

apg-get install traceroute

(если ругается, то можно добавлять  ключ --fix-missing при любой инсталляции пакетов)

apt install inetutils-traceroute --fix-missing
apt install nmap

3.
Конфигурирование Mysql. Необходимо создать БД для zabbix и наделить пользователя zabbix необходимыми правами:

если при инсталляции mysql не был задан пароль для root, то установим его сначала:
зайдем  клиентом mysql:
mysql -u root -p
получим приглашение:
mysql>

use mysql;
update user set authentication_string=PASSWORD("root-pass") where User='root';

создадим БД для zabbix:

create database zabbix character set utf8 collate utf8_bin;

дадим права:

grant all privileges on zabbix.* to zabbix@localhost identified by 'zabbix-pass';
quit;

Установим структуру таблиц для БД zabbix (я расcчитывал, что они там уже будут, если я устанавливал zabbix в одном дистрибутиве с mysql, но это было не так):

cd /usr/share/doc/zabbix-server-mysql/
gzip -d create.sql.gz
mysql -u zabbix -p zabbix < create.sql

-----------------
4.
Конфигурирование Apache:
надо раcкоментарить и установить правильную date.timezone в файле /etc/zabbix/apache.conf:
<IfModule mod_php5.c>
php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 2M
php_value max_input_time 300
php_value always_populate_raw_post_data -1
php_value date.timezone Europe/Moscow
</IfModule>
<IfModule mod_php7.c>
php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 2M
php_value max_input_time 300
php_value always_populate_raw_post_data -1
php_value date.timezone Europe/Moscow
</IfModule>

5.
Конфигурирование zabbix. По умолчанию zabbix имеет минимальные настройки для своей работы, поэтому их надо сразу увеличивать, чтобы он быстро определял новые узлы и не ругался на отсутствие ресурсов. В файле /etc/zabbix/zabbix_server.conf увеличить до ~:

StartPollers=50
StartPreprocessors=64
StartPollersUnreachable=10
StartDiscoverers=64
CacheSize=128M
HistoryCacheSize=64M
HistoryIndexCacheSize=16M
TrendCacheSize=16M
ValueCacheSize=32M

Затем надо все компоненты перестартовать и зайти через веб интерфейс http://"your lan ip"/zabbix
логин: Admin (c заглавной буквы!)
пароль: zabbix
далее откроется "мастер" который запросит имя БД, пользователя БД и его пароль.
после чего zabbix начнет работать.

6.
Составим список хостов. (Хоть zabbix и имеет функционал поиска хостов по маске сети, но работает очень медленно, даже если интервал автообнаружения выставлен минимальный, 10-20 сек.). Опытным путем выяснилось, что он быстро находит хосты если они ему подаются в виде списка конкретных IP адресов. Поэтому этот список составим отдельной процедурой, используя NMAP (мне нужны были устройства Cisco):

nmap 192.168.0-255.1-254 -A -O -sU -p U:161 -oG - | grep -i cisco | awk '/161\/open/{print $2","}'

будет ответ типа:
192.168.1.1,
192.168.2.1,
и т.д. , запятые нужны чтобы их не вставлять самому, т.к. заббиксу они нужны.

7.
Настройка профилей автообнаружения
а) В глобальных настройках: Administaration>General>Other
указать: Default host inventory mode - Automatic
(это нужно, что бы обнаруженные хосты вносили свои инвентарные данные (название узла, версия софта, шасси и т.д.) в таблицу сразу, иначе в каждый хост
придется заходить и править эту опцию).


б) Создадим профили автообнаружения:
для начала создадим "host group", это нужно чтобы увидеть его на главном дашборде.
Сonfiguration> host groups> create host group
назовем его "Discovered hosts"
Затем создадим шаблон: configuration> host groups> create template
Назовем его: "1-auto-discover"
в нем укажем, что он принадлежит хост группе "Discovered hosts"
в  "linked templates" выбрать "Template Net Cisco IOS SNMPv2" (в нем все для Cisco, что мне нужно),
затем в "Macros" добавить {$SNMP_COMMUNITY} , если community  отличается от "public".

Теперь настроим правило автообнаружения:
Сonfiguration>Discovery>Create riscovery rule
назовем его "routers"
"Update interval" укажем 20
в поле "Check" добавим snmp v2 agent и укажем community
в OID  укажем "SNMPv2-MIB::sysDescr.0",
создадим и второй "Check" с OID  "SNMPv2-MIB::sysName.0"
в "IP range" вставляем наш список полученный NMAP, с запятыми (после последнего ip адреса ставить ничего не надо)
ОБЯЗАТЕЛЬНО убираем галочку "Enable".

Создадим будущее действие с обнаруженными хостами (поэтому и не включали ещё правило обнаружение):
Сonfiguration>Actions>Create action
Назовем его: "Auto discovery routers move to 1-auto-discover"
Type of calculation - AND
Conditions  -
A) discovery rule routers
B) Discovery status = Up
C) Service type = SNMPv2 agent

переходим  в секцию "Operations"
Operations:
Add to host groups: Discovered hosts
Link to templates: auto-1-cisco
Добавляем-сохраняем, проверяем что  галочка Еnable на данном Action "Auto discovery routers move to 1-auto-discover" установлена.
затем переходим снова на Сonfiguration>Discovery> Разрешаем наше правило обнаружения "routers"
переходим на дашборд и ожидаем появления обнаруженных хостов в группе "Discovered hosts"