Простая обработка простого вывода: 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

Pfsence оптимизация VPN и mapping с подменой src и dst IP адресов.

Накопилось куча VPN подключений, попросили сделать ещё 2.
Решил их сделать на собранном ранее кластере pfsence, смотрящим в BGP AS, с 2-я аплинками.
Главная цель - полная горячая отказоустойчивость, реализованная на всех компонентах инфраструктуры, как связи так и виртуализации.
Вторая цель это возможность проверки соединений  к самим  сервисам внутри ВПН, т.к. при обычном построении IPSEC фазы 2 всегда указываются IP конечных хостов (сетей) к которым у меня нет доступа, чтобы  прямо с них проверить.
Третья цель это не мусорить маршрутизацию внутри своей локальной сети, адресами контрагентов, и решить возможные проблемы при их совпадении.
Для решения этих проблем выделил виртуальный IP адрес на pfsence, который разделяется между нодами (CARP)  pfsence и указал его в качестве нашего внутреннего для фазы 2 (для контрагентов). На этот же  виртуальный IP повесил port-forwarding с произвольными (но систематизированными) TCP портами, начиная с 5000, последовательно примапливая каждый следующий порт к необходимому TCP сервису внутри VPN:
Pfsence-virt-IP:5000->insideVPN-IP:80
Pfsence-virt-IP:5001->insideVPN-IP:443
и т.д.

Таким образом для клиента с нашей стороны полностью подменивается и dst:port , а для сервера на стороне контрагента  подменивается src (и port) и все запросы приходят с Pfsence-virt-IP.

Обычно это делается  прописыванием 2-х правил в секции NAT: port-forward и outbound ,
сначала (NAT->port-forward) начинаем слушать на нужном порту, подменяем dst:port и посылаем внутрь pfsence, затем на выходном интерфейсе (NAT->outbound) подмениваем src.
всё это прекрасно работает для статических интерфейсов. Но с IPSEC трафиком это не проходит, хотя  в настройках NAT->outbound есть интерфейс IPSEC, всё равно всё шлётся согласно существующей статической маршрутизации, т.е. не уходит в интерфейс IPSEC (pfsence не понимает что есть connected "insideVPN-IP" через IPSEC) и NAT-outbound не работает, и действительно, в какой из множества живых IPSEC его посылать?.
Как оказалось это связано с особенностями обработок цепочек фаервола при IPSEC.
Решается это применением NAT/BINAT в самой настройкt фазы 2 IPSEC подключения.

Далее приведу 2 примера полного Порт-IP маппинга для обычных интерфейсов и для IPSEC.

1) Между обычными интерфейсами:

Внутренний хост  10.143.8.26 цель которого попасть на 10.0.1.186:80, у  10.143.8.26 нет возможности быть смаршрутизированным на 10.0.1.186, но есть возможность достигнуть 10.129.170.130 (виртуальный IP pfsence) на  интерфейсе ОРТ2.
Pfsence не является шлюзом и пропускает простой транзитный трафик.
10.0.1.128 это IP LAN интерфейса pfsence, хост 10.0.1.186  не имеет маршрутной информации о 10.143.8.26, но достижим с 10.0.1.128. Выберем порт 9191, который будет слушать на 10.129.170.130.
Для этого прописываем в разделе:

принимаем подключение с определенного IP  10.143.8.26 (указываем в advanced option), иначе будет создано (автоматически в разделе Rules/OPT2) правило которое разрешит ВСЕМ доступ к данному форвардингу: 10.129.170.130:9191
Обязательно пишем дескрипшен, чтобы потом найти созданное автоматом правило в Rules, оно будет таким: "NAT <desc...>"

Затем создаем ещё одну трансляцию, но уже outbound:

Здесь указываем, что выходя через LAN (а определяется это статической маршрутизацией), то подменить для совпадающих IP , src на "Interface Address".

2) Маппинг в VPN

Внутренний хост  10.30.0.62 (которому надо через ВПН подключиться (в идеале) к внешнему 192.168.99.1)

Виртуальный IP на pfsence (Pfsence-virt-IP)  10.129.170.130 , он доступен внутренним хостам (и 10.30.0.62) без дополнительной маршрутизации. 10.129.170.130 будет слушать на 5000 порту, 10.129.170.130 также является нашим внутренним IP для VPN (т.е. у него 2 независимых роли, можно использовать и 2 разных IP).

Опускаю процесс поднятия IPSEC Phase 1 - он обычный.
Фазу 2 поднимаем для оговоренных с Той стороной пары IP адресов (сетей)   10.129.170.130 <->  192.168.99.1

Первое:
прописываем Port-Forward (аналогично пункту 1), в котором описываем подмену DST IP(:port) с 10.129.170.130:5000 на 192.168.99.1:80

Второе:
Для IPSEС обычный NAT - Outbound не работает, поэтому будем использовать опцию NAT/Binat в phase2 IPSEC соединения.
Добавляем еще одну запись phase2 (2-ю, 3-ю если понадобится), где указываем  SRC IP из нашей локальной сети, которое надо подменить IP на оговоренный для нас  с контрагентом (10.129.170.130).

IP на другой стороне VPN - 192.168.99.1 (оно знает только о 10.129.170.130).

Проверка скорости внутри локальной сети и увеличение сетевой производительности для windows 7-10

В последнее время участились жалобы на медленную передачу файлов по протоколу SMB в windows. Канал связи этим протоколом (SMB в один поток) и раньше не мог утилизироваться больше 20-30 % доступной скорости, а сейчас стал не более 5-10%. Ни подбор MTU, заведомо проходящий без фрагментации, ни повышение приоритета, ничего не помогает. Поэтому было решено прикрутить сервис альтернативной проверки скорости, не использующий прокол SMB и Проводник. Для это был найден  не очень загруженный Линукс с apache и установлен из github.com один из доступных HTML5 speedtest-еров.
процесс установки:

https://github.com/adolfintel/speedtest


============

смена MTU:


1) получаем список интерфейсов:

netsh interface ipv4 show subinterfaces

2) изменяем MTU:

netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent



так как это не помогает, то надо тюнить размер окна:



один из путей

netsh interface tcp set global autotuninglevel=disabled

netsh interface tcp set global rss=disabled

netsh interface tcp set global chimney=disabled

netsh interface tcp set global netdma=disabled

и изменить настройки адаптера:

--

полнее здесь: https://www.softjoys.pro/interesting/53

мне не помогло, но может поможет в другой ситуации



этот метод мне частично помог, особенно 1-й пункт (скорость увеличилась в 2 раза, с 5-10% до 10-20% от способности канала):

netsh interface tcp set heuristics wsh=disabled

netsh int tcp set global rss=enabled

netsh interface tcp set global autotuning=experimental

netsh interface tcp set global congestionprovider=ctcp
В заключении, как мне кажется, скорость теперь только функция от задержки,
и при задержках в 100 мс, добиться максимальной скорости по SMB практически невозможно. подробно тут:
https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

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



<Directory /usr/local/apache2/htdocs/listme>

  Options +Indexes
</Directory>
для правильного отображением названий файлов на русском языке необходимо добавить в файл .htaccess следующий код:
IndexOptions +Charset=UTF-8

--

Эмуляция port-mapping в cisco

Часто бывает необходимо, при пробросе  извне NAT вовнутрь сети, сменить не только destination, но и source (wan) IP  адреса, чтобы не заморачиваться с наличием маршрута по умолчанию на локальном устройстве куда идет перенаправление (в этом случае достаточно иметь локальную доступность (маршрутизацию) между пограничным роутером и  целевым внутренним  пунктом назначения). В Cisco появилась опция на интерфейсах ip nat enable (в дополнении к ip nat inside,outside), которая позволяет NAT-транслировать поток 2 раза, как по входу, так и по выходу одновременно. Т.е. входящие из WAN пакеты приходят на стандартный ip nat inside source..  (стандартная конструкция на интерфейсах: ip nat outside, inside), при этом подменивается только адрес назначения на локальный, но исх. адрес (wan ip) остается прежним. Затем мы можем включить ещё одну трансляцию, которая, для уже ранее преобразованного  destinaton IP, подменяет и source IP на применяемые во внутреннем интерфейсе. Этого нельзя было достигнуть раньше, т.к. надо было иметь роли inside, outside на обоих интерфейсах одновременно. Сейчас применив команду ip nat enable мы объясняем роутеру, что нам именно это и нужно. Конфиг выглядит примерно так:

interface Vlan1
description WAN
ip address 10.100.105.224 255.255.255.0
 ip nat outside
 ip nat enable
!
interface Vlan3
 description LAN
 ip address 192.168.224.1 255.255.255.0
 ip nat inside
 ip nat enable
!
ip route 10.144.0.0 255.255.0.0 192.168.224.8
!- узлы в сети 10.144.0.0/16 знают только 192.168.224.0/24, ни ничего не знает о 10.100.105.224
!- и других IP  (10.0.1.0/24) за WAN интерфейсом
ip route 10.0.1.0 255.255.255.0 10.100.105.1
!-- нат для приема из WAN соединений на 222 порт и пересылке его во внутрь на 10.144.0.157
!-- 22 порт
ip nat inside source static tcp 10.144.0.157 22 10.100.105.224 222 extendable
!--- подменяем исх. IP с 10.0.1.ХХХ на 192.168.224.1 (Vlan3)
ip nat source list 101 interface Vlan3 overload
!-- указываем что подменяем только для 10.144.0.157  порт 22
access-list 101 permit tcp 10.0.1.0 0.0.0.255 host 10.144.0.157 eq 22

Сети 10.0.1.0/24 и 10.144.0.0/16  не имеют никакой связности, и маршрутной информации друг о друге, маршруты по умолчанию указывают на другие роутеры и т.д. Но в итоге, с узлов сети 10.0.1.0/24 можно подключиться, через примапленный порт 222  (10.100.105.224 ) и уже с другого IP (192.168.224.1) инициировать подключение к 10.144.0.157 22.

Редкий случай 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

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

Расширение размера диска на 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"