По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
SNMP (Simple Network Management Protocol) - стандартный протокол для запроса информации о состоянии сетевых устройств, и он является pull протоколом - это означает, что SNMP обязан на регулярной основе запрашивать информацию о состоянии устройств - SNMP-коллекторы опрашивают устройства, а SNMP-агенты на устройствах передают данную информацию.
Частота опросов основывается на нескольких факторах, таких как:
Степень необходимой детализации получаемой информации;
Объем доступного места на хранилище;
Срок хранения данной информации;
SNMP является широко распространенным протоколом - в свободном доступе находится как достаточно много решений-коллекторов с открытым кодом, так и коммерческих вариантов - причем существуют как программные решения, так и “железные”. Маршрутизаторы и свичи чаще всего являются SNMP-агентами, также как и три основных операционных системы - Windows, Mac OS и Linux. Но с небольшой поправкой, на них SNMP служба должна быть запущена вручную.
Важно: SNMP может предоставить много полезной информации о “здоровье” оборудования, но необходимо помнить, что всегда нужно использовать безопасную версию SNMP протокола - с настроенной аутентификацией и нестандартной Community строкой.
Версии SNMP протокола
Всего существует три основных (они же и повсеместно используемые) версии SNMP протокола, в нашем случае мы будем использовать третью версию. Ниже, на всякий случай, приведено краткое описание каждой из версий.
SNMP v1
Первая версия является оригинальной версией и до сих пор используется, даже практически спустя тридцать лет. В данной версии нельзя применить никакие меры для повышения безопасности помимо Community строки, которая является чем-то вроде пароля. Если данная строка на Коллекторе соответствует строке на Агенте, то Коллектор сможет запросить информацию. Именно поэтому так важно изолировать SNMP и поместить его в отдельную подсеть и изменить Community строку.
SNMP v2c
Версия 2с привнесла дополнительные фичи в SNMP, но основным инструментом повышения безопасности все еще является Community строка. Следующая версия (v3) является предпочтительным вариантом, но некоторые организации все еще используют v1 и v2c.
SNMP v3
Третья версия имеет в себе фичи шифрования и аутентификации, а также способна отправлять настройки на удаленные SNMP-агенты. Данная версия является предпочтительной, но необходимо чтобы и Коллектор, и Агент поддерживали её. Несмотря на то, что SNMP v3 позволяет удаленно конфигурировать девайсы, большинство организаций не используют данную фичу - для этих целей используются такие решения как Ansible, Puppet, Chef или проприетарные системы управления.
Настройка на маршрутизаторе MikroTik
На большинстве устройств Community строкой является слово “public” - и этот факт широко известен, к примеру порт сканнер Nmap автоматически будет пробовать данный вариант. Если данная строка не была изменена, вы, по сути, предоставляете очевидную лазейку злоумышленникам. К сожалению, на маршрутизаторах MikroTik данную строку нельзя отключить или удалить, но её можно изменить и запретить.
/snmp community set 0 name=not_public read-access=no write-access=no
Затем необходимо создать SNMP Community со следующими параметрами:
Нестандартное имя;
Только чтение;
Аутентификация;
Шифрование;
Для этого можно использовать команду ниже - она сделает все необходимое, но, естественно, вам необходимо поменять строки wow_password и awesome_password на актуальные пароли, которые будут использоваться у вас в системе. Также поменяйте имя строки на любое другое - в примере используется имя perch_pike.
/snmp community add name=perch_pike read-access=yes write-access=no authentication-protocol=SHA1 authentication-password=wow_password
encryption-protocol=AES encryption-password=awesome_password security=private
Осталось выполнить всего одну команду для включения SNMP и настройки вашей локации и контактной информации для устройства:
/snmp set contact="Aristarh @ Merion Networks" location="Internet, RUS" enabled=yes
Заключение
SNMP - широко известный протокол, который также хорошо поддерживается компанией MikroTik и остальными производителями. Всегда используйте нестандартные Community строки, аутентификацию и шифрование, чтобы быть на 100% уверенными в том, что злоумышленники не могут получить информацию об устройствах в вашей сети - и тогда SNMP будет верным помощником в поддержке вашей сети.
В данной статье пойдет речь о модуле под названием Configuration File Editor, модуле, который позволяет редактировать дополнительные (custom) файлы конфигурации в браузере – обычно эти файлы редактируются с помощью CLI или сторонних программ, таких как WinSCP.
Что бы открыть данный модуль, необходимо в выпадающем меню вкладки Admin -> Config Edit
Как видно выше – в модуле можно создать новый файл, и так же доступны две вкладки:
Asterisk Custom Configuration Files – данные файлы можно редактировать, практически все Custom файлы изначально пустые. Кроме того, можно создавать совершенно новые файлы. Важно помнить, что после создания нового файла необходимо будет применить конфиг с помощью кнопки Apply Config
Asterisk System Configuration Files – данные файлы являются системными и их нельзя редактировать в данном модуле
Обратите внимание на надпись «File is not writable» - кнопки «Save» и «Delete» так же неактивны.
Важно:
Для подключения custom файла в оригинальном файле должна быть запись следующего вида:
include ***_custom.conf
Однако, через данный модуль добавить данную строчку невозможно, но, в большинстве системных файлов данные команды уже присутствуют.
Если же вы создадите новый файл, с помощью кнопки + Add New File, то необходимо будет всё же использовать CLI для его подключения. К примеру, для использования файла test_newsettings_custom.conf, необходимо будет в нужный для вас системный .conf файл (который является системным файлом) прописать следующую строку:
include test_newsettings custom.conf
От себя добавлю, что чаще всего данный модуль может пригодиться не для редактирования, а для просмотра нужных вам файлов.
BGP - это сложный протокол маршрутизации, и бывают ситуации, когда что-то идет не так как надо. Кроме того, что он сложный, он также совершенно отличается от наших IGP протоколов (OSPF и EIGRP). В этой статье мы начнем с рассмотрения неполадок, возникающих в установлении соседства BGP, и как только это разберем, перейдем к проблемам с объявлением маршрутов, которые должны или не должны появляться!
Видео: Основы BGP за 7 минут
Урок 1
Начнем с нескольких простых сценариев. Два маршрутизатора BGP, которые подключены и настроены для EBGP. К сожалению, мы видим это, когда проверяем соседство BGP:
Когда два маршрутизатора EBGP, которые напрямую подключены, не образуют рабочее соседство BGP, может произойти ряд ошибок:
Layer 2 не позволяет нам добраться до другой стороны.
Проблема уровня 3: неправильный IP-адрес на одном из маршрутизаторов.
Список доступа, блокирующий TCP-порт 179 (BGP).
Неправильный IP-адрес настроен для соседнего маршрутизатора BGP
Мы можем использовать команду show ip bgp summary, чтобы проверить IP-адреса маршрутизаторов. Они, совпадают.
Мы выполним эхо запрос, с помощью команды ping. Видим, что, пакеты не могут добраться до другой стороны.
Проверяем интерфейсы и видим, что кто-то ввел команду отключения интерфейса.
R2(config)#interface fa0/0
R2(config-if)#no shutdown
"Поднимаем" интерфейс
Это прекрасно! Наше соседство BGP установлено. Это было легко!
Итог урока: убедитесь, что ваш интерфейс работает.
Урок 2
Следующая неполадка похожа на предыдущую, но немного отличается. Мы используем те же маршрутизаторы и номера AS, но на этот раз необходимо установить соседство BGP между интерфейсами обратной связи.
Посмотрим, как выглядит конфигурация BGP:
Вот конфигурация BGP. Как вы видите, мы используем loopback интерфейсы для установления соседства BGP-соседей.
Оба маршрутизатора показывают, что их сосед BGP бездействует. Есть ряд вещей, которые мы должны проверить здесь:
Доступен ли IP-адрес соседа BGP? Мы не используем прямые линии связи, поэтому у нас могут возникнуть проблемы с маршрутизацией.
TTL IP-пакетов, которые мы используем для внешнего BGP, равен 1. Это работает для сетей с прямым подключением, но, если они не подключены напрямую, нам нужно изменить эту настройку.
По умолчанию BGP будет получать обновления с IP-адреса, ближайшего к соседу BGP. В нашем примере это интерфейс FastEthernet. Это то, что мы должны изменить.
Начнем с маршрутизации. Оба маршрутизатора знают только о своих напрямую подключенных сетях. Чтобы достичь loopback интерфейсов друг друга, мы будем использовать статическую маршрутизацию.
R1(config)#ip route 2.2.2.2 255.255.255.255 192.168.12.2
R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1
Два статических маршрута должны выполнить эту работу.
Отправка ping на IP-адрес 2.2.2.2 и получение его из нашего собственного loopback интерфейса доказывает, что оба маршрутизатора знают, как связаться с loopback интерфейсом друг друга.
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2
Команда ebgp-multihop изменяет TTL на 2.
Мы можем включить отладку, чтобы увидеть прогресс. Ясно видно, что R2 использует IP-адрес 192.168.12.2, а R1 отказывается от соединения.
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R2(config-router)#neighbor 1.1.1.1 update-source loopback 0
Используйте команду update-source, чтобы изменить IP-адрес источника для обновлений BGP.
Соседство BGP работает!
Итог урока: маршрутизаторам BGP не требуется устанавливать соседство с использованием напрямую подключенных интерфейсов. Убедитесь, что маршрутизаторы BGP могут связаться друг с другом, что пакеты BGP получены из правильного интерфейса, и в случае EBGP не забудьте использовать команду multihop.
Урок 3
Продолжим рассмотрение некоторых проблем IBGP. Два маршрутизатора в одной AS и вот конфигурация:
Легко и просто. Маршрутизаторы используют напрямую подключенные IP-адреса для соседства BGP.
Жаль ... мы не становимся соседями. Что может быть не так? Мы используем напрямую подключенные интерфейсы, поэтому не так много проблем, если не считать проблемы L2 / L2.
Отправка пинга с одного маршрутизатора на другой доказывает, что L2 и L3 работают нормально. Как насчет L3? У нас могут быть проблемы с транспортным уровнем.
Я не могу подключиться к TCP-порту 179 с обоих маршрутизаторов. Это звоночек в сторону того, что что-то блокирует BGP?
Вот оно! Это Служба безопасности.…
Кто-то решил, что было бы неплохо "обезопасить" BGP и заблокировать его списком доступа.
R2(config)#interface fastEthernet 0/0
R2(config-if)#no ip access-group 100 in
Удалим список доступа.
Итог урока: не блокируйте TCP-порт BGP 179.
Урок 4
Следующая проблема IBGP. Это похоже на ситуацию с EBGP ранее...мы будем использовать loopback-интерфейсы для установления соседства BGP, вот конфигурации:
Ничего особенного, IBGP и мы используем loopback интерфейсы.
Не повезло здесь ... нет соседей. Давайте сначала проверим, могут ли маршрутизаторы получить доступ к loopback интерфейсам друг друга:
Быстрый взгляд на таблицу маршрутизации показывает нам, что это не так. Мы могли бы исправить это с помощью статического маршрута или IGP. Обычно мы используем IGP для IBGP для объявления loopback интерфейсов. Сейчас будем использовать OSPF:
R1(config)#router ospf 1
R1(config-router)#network 1.1.1.0 0.0.0.255 area 0
R1(config-router)#network 192.168.12.0 0.0.0.255 area 0
R2(config)#router ospf 1
R2(config-router)#network 192.168.12.0 0.0.0.255 area 0
R2(config-router)#network 2.2.2.0 0.0.0.255 area 0
Набор правильных команд OSPF должно сделать свою работу!
Отправка эхо-запроса, чтобы проверить, знают ли маршрутизаторы и как связаться с сетями друг друга, успешен.
Тем не менее, соседство BGP по-прежнему отсутствует
Отладка показывает, что в соединении отказано, а также показывает локальный IP-адрес, который используется для BGP. Кажется, кто-то забыл добавить команду update-source, так что давайте исправим это!
R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R2(config)#router bgp 1
R2(config-router)#neighbor 1.1.1.1 update-source loopback 0
Точно так же, как EBGP, мы должны установить правильный источник для наших пакетов BGP.
Задача решена! Единственное отличие от EBGP в том, что нам не нужно менять TTL с помощью команды ebgp-multihop.
Итог урока: распространенная практика настройки IBGP между loopback интерфейсами. Убедитесь, что эти loopback доступны и обновления BGP получены из loopback интерфейса.
Теперь, рекомендуем почитать вторую часть статьи по траблшутингу протокола BGP.