По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье мы рассмотрим настройку BGP-оповещения для Network Layer Reachability Information (NLRI), а также конфигурацию политики маршрутизации BGP.
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Построение маршрута протоколом BGP
Формирование соседства в BGP
Видео: Основы BGP за 7 минут
Оповещения NLRI
Прежде чем мы начнем настраивать оповещения NLRI, используя различные команды, давайте сначала обсудим старую функцию BGP, которую Cisco отключает по умолчанию. Эта функция называется синхронизацией BGP. Для проверки того, что Cisco отключила эту функцию на вашем устройстве, выполните команду show running-configuration на одном из устройств BGP, и в выводимой информации, под пунктом «процессы» BGP, вы увидите сообщение no synchronization. Если эта функция включена, функция синхронизации не позволяет спикеру BGP вводить префиксы в BGP, если нет коррелированной записи для префикса в базовом IGP (или статических маршрутах). Это помогает предотвратить ситуации типа "черная дыра" (black hole), когда устройства на маршруте не работают с BGP и не могут переадресовать префикс BGP, потому что у них нет маршрута к этому префиксу из их IGP. Эта функция отключена по умолчанию из-за создания множества различных механизмов масштабируемости, существующих в BGP, которые позволяют настроить топологию iBGP без требования полной сетки одноранговых узлов iBGP. Еще одна причина, по которой он отключен, заключается в том, что он поощряет перераспределение префиксов BGP в базовый IGP, и это не безопасно.
Существует причина, по которой Cisco уходит от использования команды network для настройки IGPs в CLI. Не очень хорошая идея в программировании, чтобы одна команда выполняла очень разные вещи, и когда она используется в разных областях. Это относится и к команде network. При использовании в IGP команда включает протокол на интерфейсе (а также влияете на то, какие префиксы объявляются), но в BGP у команды network другое назначение. Она не включает BGP на определенных интерфейсах, вместо этого она объявляет префикс, который существует (каким-то образом) на локальном устройстве, и вводит его в BGP.
Хотя префикс, который вы могли бы объявить в BGP, чаще всего встречается в вашем IGPs в таблице маршрутизации. Вы можете использовать другие методы для создания префикса для оповещения. Например, вы можете создать интерфейс обратной связи, который обладает префиксом сети, который вы хотите объявить. Или вы можете создать статический маршрут или даже статический маршрут, указывающий на Null0.
Одна маленькая хитрость, связанная с командой network в BGP, заключается в том, что, если ваша маска подсети для вашего префикса не находится на классовой границе IP- адреса (например, 10.0.0.0/8), то вам нужно не забыть использовать ключевое слово mask и указать правильную маску при использовании команды. Пример 1 показывает создание двух петлевых интерфейсов и объявление их префиксов в BGP. Обратите внимание, что этот пример также показывает проверку этих префиксных объявлений на маршрутизаторе ATL.
Пример 1: Использование команды Network в BGP
TPA1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)#interface loopback 192
TPA1(config-if)#ip address 192.168.1.1 255.255.255.0
TPA1(config-if)#exit
TPA1(config)#interface loopback 172
TPA1(config-if)#ip address 172.16.10.1 255.255.255.0
TPA1(config-if)#exit
TPA1(config)router bgp 100
TPA1(config-router)#network 192.168.1.0
TPA1(config-router)#network 172.16.10.0 mask 255.255.255.0
TPA1(config-router)#end
TPA1#
ATL#
ATL#show ip bgp
Хотя команда network проста и удобна, она не была бы эффективной, если бы у вас было много префиксов для оповещения. Другой вариант- перераспределить префиксы в BGP из IGP или статических маршрутов. Пример 2 демонстрирует перераспределение префиксов, которые были получены через EIGRP, в BGP. Обратите внимание при проверке, что исходный код для этих префиксов отображается как (?) указывает на неизвестность.
Пример 2: перераспределение префиксов в BGP
TPA1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 100
TPA1(config-router)#redistribute eigrp 100
TPA1(config-router)#end
TPA1#
ATL#show ip bgp
Когда вы начинаете объявлять (оповещать) NLRI в BGP, вы можете столкнуться с префиксами в вашей таблице BGP (показанной с show ip bgp), которые имеют код состояния (r) вместо ожидаемого допустимого кода состояния (*). Код состояния (r) указывает на сбой RIB, означающий, что BGP попытался поместить префикс в таблицу BGP, но не смог из- за какой-то проблемы.
Наиболее распространенной причиной отказа RIB является административное расстояние (AD). Например, IBGP узнал префиксы несущие ужасные объявления AD из 200. Это означает, что если ваш маршрутизатор получил префикс через IGP (даже такой плохой, как RIP с AD 120), то он будет предпочтительнее префикса IBGP. В результате протокол BGP получивший это объявление AD, не отметит префикс как действующий. Обратите внимание, что это, как правило, не происходит с префиксами EBGP-learned, поскольку они имеют очень предпочтительное объявление 20 (по умолчанию).
Очень часто, если желательно иметь префикс в IGP и BGP, администраторы будут манипулировать значениями AD на своих маршрутизаторах, чтобы улучшить AD IBGP. Например, в случае RIP и BGP администратор мог бы установить AD изученных маршрутов IBGP на 119, чтобы сделать их предпочтительными по сравнению с используемым IGP.
В дополнение к выявлению сбоев RIB в результатах команды show ip bgp, вы можете использовать более прямую команду show ip bgp rib-failure, чтобы увидеть любые префиксы в этом состоянии. Это особенно полезно в случае массивных таблиц BGP.
Настройка политики маршрутизации BGP
Довольно часто встречаются топологии, в которых вы явно не хотите объявлять префиксы в своей таблице BGP, или вы не хотите получать определенные префиксы от узла BGP. К счастью, в вашем распоряжении есть много инструментов для этого. Например, вот только некоторые методы, которые вы могли бы использовать для фильтрации префиксов:
Distribute lists
Extended ACLs
Prefix lists
AS Path filters
Route maps
Пример 3 демонстрирует один из методов фильтрации. Выбран подход route map, потому что все (и это правильно) любят карты маршрутов.
Пример 3: Использование route map в качестве префиксного фильтра в BGP
ATL# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#ip access-list standard MYPREFIX
ATL(config-std-nacl)#permit 192.168.1.0 0.0.0.255
ATL(config-std-nacl)#exit
ATL(config)#route-map MYMAP deny 10
ATL(config-route-map)#match ip address MYPREFIX
ATL(config-route-map)#exit
ATL(config)#route-map MYMAP permit 20
ATL(config-route-map)#exit
ATL(config)#router bqp 200
ATL(config-router)#neighbor 10.10.10.1 route-map MYMAP in
ATL(config-router)#end
ATL#
ATL# clear ip bqp * soft
ATL# show ip bqp
Обратите внимание, перед проверкой я запускаю команду clear ip bgp * soft. Это гарантирует, что устройство сразу же обновит информацию BGP для меня, так что мне не придется ждать истечения таймера, когда дело дойдет до конвергенции BGP на новых манипуляциях с политикой, которые мы сделали.
Помните, что BGP использует множество различных атрибутов пути вместо простой метрики, чтобы предоставить вам возможность легко настроить способ, по которому происходит маршрутизация. Ниже приведены некоторые из атрибутов пути, которыми вы могли бы манипулировать, чтобы настроить политику:
Weight
MED
Local Preference
AS Path
Можно спросить себя, как AS Path могут быть использованы в целях маршрутизации. Поскольку манипуляция AS Path часто выполняется с помощью AS Path Prepending. Вы отравляете префикс, добавляя свой собственный номер AS к пути, чтобы сделать более длинным (менее предпочтительным) AS Path. Как и большинство наших манипуляций с атрибутом пути, это легко сделать с помощью карты маршрута.
Давайте рассмотрим пример использования Local Preference для манипулирования политикой. Мы часто используем Local Preference, чтобы повлиять на то, как мы будем направлять исходящий трафик к префиксу BGP. Мы делаем это, устанавливая значения Local Preference, входящие по нескольким путям. Прежде чем мы начнем, поймите, что Local Preference - это значение, которое рассматривается довольно высоко в процессе принятия решения о наилучшем пути BGP, более высокое значение предпочтительно, и значения передаются только в обновлениях IBGP. Именно так имя LOCAL вошло в название Local Preference.
Для начала я объявил тот же префикс в AS 200 (ATL и ATL2) от маршрутизаторов TPA1 и TPA2 AS 100. Глядя на пример 4, Вы можете видеть, что этот префикс (192.168.1.0) может быть достигнут с помощью следующего прыжка 10.10.10.1 и что это предпочтительный путь. Альтернативный путь, который будет использоваться в случае неудачи этого пути, будет проходить через следующий переход 10.21.21.1.
Пример 4: Подготовка к использованию Local Preference
ATL# show ip bqp
Теперь пришло время поэкспериментировать и изменить данное поведение с помощью примера манипуляции атрибутом пути. Мой подход будет состоять в том, чтобы определить префикс, которым мы хотим манипулировать (192.168.1.0), и поднять значение локального предпочтения, чтобы оно было больше, чем значение по умолчанию 100 для пути к TPA2 на следующем прыжке 10.21.21.1. Я делаю это, манипулируя префиксом, когда он входит через путь 10.21.21.1 .
Пример 5 показывает эту конфигурацию.
ATL# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#ip access-list standard OURPREFIX
ATL(config-std-nacl)#permit 192.168.1.0 0.0.0.255
ATL(config-std-nacl)#exit
ATL(config)#route-map SETLOCALPREF permit 10
ATL(config-route-map)#match ip address OURPREFIX
ATL(config-route-map)#set local-preference 110
ATL(config-route-map)#exit
ATL(config)#route-map SETLOCALPREF permit 20
ATL(config-route-map)#exit
ATL(config)#router bqp 200
ATL(config-router)#neighbor 10.21.21.1 route-map SETLOCALPREF in
ATL(config-router)#end ATL#
ATL# clear ip bqp * soft
ATL# show ip bqp
Обратите внимание, что предпочтительный путь теперь проходит через следующий переход 10.21.21.1, как мы и хотели. Для этого префикса также отображается значение Local Preference - 110. Это более высокое значение является предпочтительным и изменяет выбор, сделанный процессом выбора наилучшего пути BGP.
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 будет верным помощником в поддержке вашей сети.
От проблем и неполадок не застраховано ничто и IP-АТС Asterisk – не исключение. Неправильная конфигурация, неудачное обновление, неполадки в сети, сбой у провайдера - всё это может тем или иным образом сказываться на работе Вашей системы IP-телефонии. Для того, чтобы решить эти проблемы или хотя бы найти правильный путь, в сторону которого следует “копать”, нужно собственно, услышать показания “пациента”, то есть – нашего сервера IP-АТС Asterisk. Говоря простым языком – нужно снять логи. А с помощью модуля FreePBX, о котором мы хотим рассказать в данной статье, сделать это будет ещё проще.
Итак, для того чтобы решить проблему нам нужна информация. Но слишком большое количество информации может быть так же бесполезно, как и её отсутствие. В данной статье мы покажем, как собрать полезную и краткую информацию.
Где Asterisk хранит логи?
Чтобы знать что “лечить”, нужно знать где искать. Информация, которую мы ищем содержится во множестве лог-файлов, которые хранит сервер.
Важно! Обратите внимание, что в зависимости от используемого дистрибутива Linux, расположение лог-файлов у Вас может быть другим.
Расположение
Описание
/var/log/asterisk/fail2ban
Журнал событий модуля fail2ban
/var/log/asterisk/freepbx.log
Журнал событий модулей FreePBX
/var/log/asterisk/freepbx_security.log
Журнал событий безопасности
/var/log/asterisk/full
Журнал событий Asterisk каждого уровня. Обычно используется для поиска трассировок старых звонков
/var/log/dmesg
Журнал событий уровня ядра
/var/log/httpd/access_log
Журнал событий доступа к Apache
/var/log/httpd/error_log
Журнал ошибок web сервера Apache
/var/log/messages
Системный журнал событий Linux
/var/log/yum.log
Журнал действий, выполненных через yum
Названия файлов могут быть дополнены информацией о дате, за которую создан файл, указанную после (.) или (-)
Фильтрация
Некоторые из этих файлов могут содержать тысячи записей, поэтому, если Вы знаете, какое событие ищете, то отфильтруйте лог по данному событию или хотя бы сократите его, например, оставьте только информацию за определённое время.
Чтобы найти нужную информацию, используйте утилиту grep, которая позволяет искать определённые шаблоны или части слов в большом количестве записей.
grep 10987 /var/log/asterisk/full
В примере выше мы ищем совпадение записей по числам 10987 в полном журнале событий Asterisk
Если Вы хотите попросить помощи на общедоступных площадках, например, на форуме, то рекомендуем удалить или изменить всю приватную/ секретную информацию, которую может содержать лог, такую как номера телефонов, публичные IP-адреса, ваш account ID у провайдера, пароли и т.д.
Модуль Support FreePBX
В версии 13 и 14 FreePBX, в модуле System Admin есть очень полезная секция - Support. Для того, чтобы попасть в неё необходимо перейти по следующему пути из дашборда кликнуть на вкладку Admin → System Admin → Support , перед Вами откроются доступные опции данной секции:
На этой странице, Вы можете скачать ZIP – файл, который будет содержать отчёт с необходимой системной информацией и логи для дальнейшего исследования или же для отправки в техническую поддержку.
Для включения информации в отчёт используйте кнопки Yes/No. Рассмотрим каждый пункт, который можно включить в отчёт:
FreePBX Versions - Список всех установленных модулей и их версии
System Information - Информация об операционной системе
Asterisk Logs - Журналы событий Asterisk за последние 24 часа
Firewall Setting - Вывод текущих настроек ip-tables
ASTDB Dump - Полный дамп ASTBD (Не путать с MySQL)
License Information - Информация о лицензировании и статусе сервера
Dialplan - Полный дайл-план, созданный FreePBX (включая кастомные файлы _custom)
SIP Settings - Настройки SIP (Может содержать секретную информацию)
PJSIP Settings - Настройки PJSIP (Может содержать секретную информацию)
IAX Settings - Настройки IAX (Может содержать секретную информацию)
Как только Вы выбрали какую информацию хотите включить в отчёт, нажмите кнопку Download и сохраните ZIP файл на свой компьютер.
На этой странице, Вы также можете установить ssh, ключи, которые позволят сотрудникам технической поддержки Sangoma подключиться к Вашей системе без необходимости разглашать всякие пароли.