По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье мы рассмотрим некоторые протоколы, такие как NTP, syslog и SNMP. Все они используются для мониторинга "работоспособности" вашей сети. При правильной настройке они могут быть очень полезны...если они не работают, может быть действительно трудно выяснить, когда в сети произошло определенное событие и что его вызвало. Syslog и SNMP используются для мониторинга сети, NTP используется для обеспечения того, чтобы наша регистрационная информация имела правильное время и дату.
Мы начнем с NTP - это не очень сложный протокол, но есть несколько вещей, которые могут пойти не так:
Фильтрация трафика NTP: списки доступа могут блокировать трафик NTP.
Проблемы аутентификации NTP: NTP поддерживает аутентификацию, клиент и сервер должны использовать одинаковые настройки.
Слишком большое временное смещение: если временное смещение между клиентом и сервером слишком велико, для синхронизации потребуется очень много времени.
Stratum level слишком высокий: Stratum level составляет от 1 (лучший) до 15 (худший). Stratum level 16 считается непригодным.
Фильтр источника NTP-сервера: NTP-серверы можно настроить так, чтобы разрешать только клиентам с определенных IP-адресов.
Давайте разберем эти вопросы. Мы будем использовать два маршрутизатора для этого:
Урок 1
R1 будет нашим NTP-клиентом, а R2 будет NTP-сервером. Есть две полезные команды, с которых мы должны начать:
Команды говорят нам, что R1 имеет адрес 192.168.12.2, настроенный как сервер NTP, и в настоящее время он не синхронизирован. Давайте проверим, получает ли R1 пакеты NTP, это лучше всего сделать с помощью отладки:
Эта отладка говорит нам, что R1 отправляет NTP-пакеты, но мы ничего не получаем от NTP-сервера. Убедитесь, что NTP-сервер разрешен для прохождения:
R1 использует UDP-порт 123, убедитесь, что он не заблокирован:
R1(config)#interface FastEthernet 0/0
R1(config-if)#no ip access-group NO_TIME in
После удаления списка доступа, NTP сможет использовать пакеты NTP с сервера:
Вот конечный результат:
Часы теперь синхронизированы. Другая проблема, которую вы можете обнаружить с помощью debugging NTP, - это несоответствие аутентификации:
R1(config)#ntp server 192.168.12.2 key 1
R1(config)#ntp authentication-key 1 md5 MY_KEY
Мы настроим R1 так, чтобы он принимал только NTP-пакеты от NTP-сервера, которые аутентифицированы с определенным ключом. Сервер NTP, однако, не использует никакой формы аутентификации. Мы можем найти эту ошибку с помощью следующей отладки:
Это расскажет нам о:
Убедитесь, что ваши настройки аутентификации NTP совпадают с обеих сторон. Когда разница во времени / дате между сервером NTP и клиентом велика, синхронизация займет много времени. Прямо сейчас часы выглядят так:
Установка часов на NTP-клиенте на что-то близкое к NTP-серверу значительно ускорит процесс синхронизации:
R1#clock set 18:00:00 30 January 2015
Через несколько минут часы на клиенте NTP должны быть синхронизированы.
Еще одна проблема с NTP заключается в том, что stratum level ограничен, мы можем использовать значения от 1 (лучший) до 15 (худший). Если у сервера NTP есть stratum level 15, то клиент NTP не сможет синхронизировать, так как 16 считается недостижимым.
Отладка пакетов NTP на клиенте покажет это:
R1 никогда не сможет синхронизировать себя, поскольку NTP-сервер объявляет себя как stratum -уровень 15. Вы можете исправить это, установив более низкое значение stratum - уровня NTP на своем NTP-сервере:
R2(config)#ntp master 2
Мы изменяем его на значение 2 уровня. Это позволяет R1 синхронизировать себя:
И последнее, но не менее важное: NTP-серверы могут быть настроены так, чтобы разрешать NTP-клиентам только с определенных IP-адресов:
Например, мы настрою его, чтобы разрешить только IP-адрес 1.1.1.1:
R2(config)#ntp access-group serve 1
R2(config)#access-list 1 permit 1.1.1.1
R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1
В этом случае нам нужно убедиться, что NTP-клиент получает свои NTP-пакеты с правильного IP-адреса:
R1(config)#interface loopback 0
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config)#ntp source loopback0
Команда NTP source скажет R1 использовать IP-адрес 1.1.1.1 из своего loopback интерфейса в качестве источника своих пакетов NTP.
Это самые распространенные ошибки NTP.
Урок 2
Давайте продолжим, посмотрев на syslog.
Наиболее распространенная проблема с системным журналом - это отсутствие информации о регистрации. По умолчанию ведение журнала включено только для консоли, а не для внешних серверов системного журнала.
Есть одна команда, которую вы можете использовать для проверки ее конфигурации:
Это говорит нам, что системный журнал включен для консоли вплоть до уровня отладки. Если вы не видите всего на консоли, то кто-то, возможно, изменил уровень ведения журнала на более низкое значение. Вот варианты:
Уровень отладки - самое высокое значение (7), поэтому он покажет все сообщения системного журнала. Если вы не видите все сообщения, убедитесь, что они установлены на уровне отладки для консоли.
По умолчанию информация системного журнала не отправляется на внешний сервер. Вы должны это настроить самостоятельно:
R1(config)#logging host 192.168.12.2
Это приведет к отправке регистрационной информации для всех уровней серьезности на внешний сервер по адресу 192.168.12.2. Убедитесь, что этот трафик не заблокирован, syslog использует UDP-порт 514.
Другая распространенная ошибка - сообщения системного журнала не отображаются в сеансах telnet или SSH. Вы можете включить это с помощью команды terminal monitor.
Урок 3
Следующий протокол, который мы обсудим, - это SNMP версии 2c и 3. Перед тем, как погрузиться в конфигурацию SNMP, убедитесь, что ваш NMS (сервер сетевого управления) может связаться с вашим устройством (агент SNMP). SNMP использует UDP-порт 161 для сообщений и UDP-порт 162 для прерываний и информирования. Убедитесь, что этот трафик разрешен.
Когда дело доходит до SNMPv2c, есть несколько общих проблем:
Неправильная community-string: community-string похожа на пароль, который используется для того, чтобы NMS могла читать или записывать данные на сетевое устройство. Если он не совпадает, SNMP не будет работать.
Ошибки списка доступа: списки доступа могут определять, какой NMS разрешено использовать community-string. Убедитесь, что вы используете правильный IP-адрес.
Перемешивание индексов: при добавлении новых интерфейсов к сетевому устройству номера интерфейсов могут больше не совпадать.
Ловушки не отправлены: если вы хотите отправить SNMP-ловушки (или сообщения), то вам нужно будет настроить это, это не делается автоматически.
Вот соответствующие команды SNMPv2c, которые вы должны проверить в случае, если SNMP не работает:
R1(config)#snmp-server community MY_COMMUNITY ro 1
R1(config)#access-list 1 permit host 192.168.1.1
Выше мы настроили сообщество под названием MY_COMMUNITY с доступом только для чтения. Мы используем access-list 1, чтобы определить, какому устройству разрешено использовать это сообщество. Убедитесь, что в списке доступа указаны правильные операторы разрешений. Следующая команда гарантирует, что индекс интерфейса остается прежним:
R1(config)#snmp-server ifindex persist
И если вы хотите отправлять SNMP-ловушки, настройте его следующим образом:
R1(config)#snmp-server enable traps eigrp
R1(config)#snmp-server host 192.168.1.1 traps version 2c MY_COMMUNITY
Это активирует ловушки SNMP для EIGRP и будет отправлено в NMS на IP-адрес 192.168.1.1 с использованием сообщества "MY_COMMUNITY". Если вы не укажете, какие ловушки вы хотите, он включит все ловушки.
SNMPv3 сильно отличается от версии 2, в безопасность и аутентификацию внесено много изменений. При поиске и устранении неисправностей SNMPv3 необходимо учитывать несколько моментов, связанных с SNMPv3:
Вложенность: с помощью SNMPv3 мы создаем пользователей, которые вложены в группы. Группы вложены в представления, которые предоставляют доступ к определенным MIBs на сетевом устройстве. Убедитесь, что ваш пользователь находится в правильной группе и что представление имеет правильные разрешения на просмотр.
Уровень безопасности: SNMPv3 поддерживает разные уровни безопасности, они должны совпадать на сетевом устройстве и NMS:
noAuthNoPriv
authNoPriv
authPriv
Параметры безопасности: SNMPv3 предлагает несколько алгоритмов хеширования и шифрования. Убедитесь, что вы настроили одинаковые алгоритмы на сетевом устройстве и NMS.
Конфигурация представлений: в представлении мы настраиваем объекты, к которым NMS разрешен доступ, убедитесь, что вы настроили правильные объекты.
Ниже приеден пример конфигурации того, что мы обсуждали:
Router(config)#snmp-server user MY_USER MY_GROUP v3 auth md5 MY_PASSWORD
priv aes 128 MY_PASSWORD
Сначала мы настраиваем пользователя с именем MY_USER, который принадлежит группе с именем MY_GROUP. Мы используем версию 3 SNMP. Для аутентификации этого пользователя мы используем MD5 и пароль "MY_PASSWORD". Для шифрования мы используем 128-битный AES и тот же пароль. Убедитесь, что на сетевом устройстве и NMS все одинаково ...
Теперь мы настраиваем группу:
Router(config)#snmp-server group MY_GROUP v3 priv read MY_VIEW access 1
Router(config)#access-list 1 permit host 192.168.1.1
Группа называется MY_GROUP, и мы используем уровень безопасности authPriv. Мы также присоединяем группу к представлению под названием MY_VIEW. Мы также используем список доступа, только NMS, использующая IP-адрес 192.168.1.1, может использовать эту группу. Давайте настроим view:
Router(config)#snmp-server view MY_VIEW system included
Router(config)#snmp-server view MY_VIEW cisco included
Это представление позволяет NMS получать доступ только к объектам в системной группе MIB-II и ко всем объектам в корпоративной MIB Cisco. Убедитесь, что вы добавили все объекты, к которым вам нужен доступ.
Информация о пользователе не отображается в конфигурации, если вы хотите увидеть пользователей, вам нужно использовать другую команду:
Эта команда показывает нам нашу учетную запись пользователя, ее алгоритмы аутентификации и шифрования и сообщает, к какой группе она принадлежит.
Теперь мы можем продолжить поиск и устранение неисправностей. В большинстве случаев вы ожидаете увидеть определенную сеть в таблице маршрутизации, но ее там нет. Далее рассмотрим несколько сценариев неправильной (или полностью не рабочей) работы EIGRP и как исправить наиболее распространенные ошибки. Ниже перечислены часто встречающиеся ошибки:
Первую часть статьи про траблшутинг EIGRP можно почитать здесь.
Кто-то настроил distribute-list, чтобы информация о маршрутах фильтровалась.
Было настроено автосуммирование или кто-то настроил суммирование вручную
Split-horizon блокирует объявление маршрутной информации.
Перераспределение было настроено, но информация из EIGRP не используется.
Перераспределение было настроено, но никакие внешние маршруты EIGRP не отображаются.
Case #1
Давайте начнем с простой топологии. OFF1 и OFF2 работают под управлением EIGRP, и каждый маршрутизатор имеет интерфейс обратной связи. Вот конфигурация обоих маршрутизаторов:
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 1.1.1.0 0.0.0.255
OFF1(config-router)#network 192.168.12.0 0.0.0.255
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config-router)#network 192.168.12.0 0.0.0.255
Все работает нормально, пока через пару недель один из пользователей не пожаловался на то, что ему не удалось подключиться к сети 2.2.2.0 / 24 из-за OFF1. Посмотрите на таблицу маршрутизации на OFF1, и вот что вы видите:
По какой-то причине нет сети 2.2.2.0 / 24 в таблице маршрутизации.
Видно, что на OFF1 не настроен distribute lists.
OFF2 содержит сеть 1.1.1.0 / 24 в своей таблице маршрутизации. Давайте выполним быструю отладку, чтобы увидеть, что происходит.
Отладка показывает нам, что происходит. Прежде чем вы увидите это сообщение, придется немного подождать, или вы можете сбросить соседство EIGRP, чтобы ускорить процесс. Как видите, в сети 2.2.2.0 / 24 отказано из-за distribute list.
Другой быстрый способ проверить это - использовать команду show ip protocol.
В этом случае использование show run могло бы быстрее обнаружить distribute-list.
Вот список доступа, доставляющий нам неприятности.
OFF2(config)#router eigrp 12
OFF2(config-router)#no distribute-list 1 out
Удалим distribute-list.
Задача решена!
Извлеченный урок: если команды network верны, проверьте, есть ли у вас distribute-list, который запрещает объявлять префиксы или устанавливать их в таблицу маршрутизации.
Имейте в виду, distribute-list могут быть настроены как входящие или исходящие, как список доступа.
Case #2
В следующем сценарии те же 2 маршрутизатора, но разные сети в loopback. Вот конфигурация:
OFF1(config)#router eigrp 12
OFF1(config-router)#network 192.168.12.0
OFF1(config-router)#network 10.0.0.0
OFF2(config)#router eigrp 12
OFF2(config-router)#network 192.168.12.0
OFF2(config-router)#network 10.0.0.0
Как вы видите - это довольно базовая конфигурация.
Глядя на таблицы маршрутизации, не видно сети 10.1.1.0 / 24 или 10.2.2.0 / 24. Видна запись для сети 10.0.0.0/8, указывающую на интерфейс null0. Эта запись отображается только при настройке суммирования и используется для предотвращения циклов маршрутизации.
Давайте включим отладку и посмотрим, что мы можем найти.
OFF2#clear ip eigrp 12 neighbors
Этой командой мы сделаем сброс соседства EIGRP, чтобы ускорить процесс. Имейте в виду, что это, вероятно, не самое лучшее, что можно сделать в производственной сети, пока вы не узнаете, что не так, но это действительно помогает ускорить процесс.
Вот наш ответ. Отладка говорит нам, что сеть 10.2.2.0 / 24 не следует объявлять, а сеть 10.0.0.0 / 8 нужно объявлять (это вкратце). Это может произойти по двум причинам:
Суммирование было кем-то настроено
Авто-суммирование включено для EIGRP.
Как вы видите, авто-суммирование включено для EIGRP. В зависимости от версии IOS авто-суммирование включено или отключено по умолчанию.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
Отключение автоматического суммирования должно помочь.
Ну что, наши сети появились в таблице маршрутизации.
Извлеченный урок: если включена автоматическое суммирование EIGRP, вы можете столкнуться с нестабильными сетями.
Case #3
Очередная проблема. В приведенном выше примере у нас есть 2 маршрутизатора, но разные сети. OFF1 содержит сеть 172.16.1.0 / 24 на интерфейсе обратной связи, а OFF2 содержит сеть 172.16.2.0 / 24 и 172.16.22.0 / 24 на своих интерфейсах обратной связи. Посмотрим конфигурацию EIGRP обоих маршрутизаторов:
Как вы видите, что все сети объявляются. Обратите внимание, что в OFF1 включено автоматическое суммирование, а в OFF2 отключено автоматическое суммирование.
Кто-то настроил суммирование на OFF2 и отправляет ее на OFF1. Суммирование создана для сети 172.16.0.0 / 16.
Однако, если посмотреть на таблицу маршрутизации OFF1, она не появится. Мы видим запись для сети 172.16.0.0 / 16, но она указывает на интерфейс null0, а не на OFF2. Что здесь происходит?
OFF2#clear ip eigrp 12 neighbors
Давайте сделаем отладку на OFF2, чтобы увидеть, объявляется ли суммирование. Выполним команду clear ip eigrp neighbors, просто чтобы ускорить процесс.
Глядя на отладку, видно, что OFF2 работает правильно. Он объявляет сводный маршрут 172.16.0.0 / 16 так, как должен. Это означает, что проблема должна быть в OFF1.
Давайте проведем отладку OFF1.
Мы можем видеть, что OFF1 получает сводный маршрут от OFF2, но решает не использовать его.
Это хороший момент для проверки таблицы топологии EIGRP. Вы видите, что он имеет суммирование сети 172.16.0.0 / 16 от OFF2 в своей таблице топологии EIGRP, но OFF1 решает не использовать ее, потому что вход через интерфейс null0 является лучшим путем.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
Решение состоит в том, что нам нужно избавиться от записи null0 в таблице маршрутизации. Единственный способ сделать это - отключить автоматическое суммирование.
Отключение автоматического суммирования удаляет запись null0, и теперь суммирование OFF2 установлено проблема решена!
Извлеченный урок: автоматическое суммирование EIGRP создает запись через интерфейс null0, которая может помешать установке суммирования, которые вы получаете от соседних маршрутизаторов.
Case #4
Есть еще одна проблема с суммированием, которую сейчас и разберем. Мы используем топологию, которую вы видите выше, и ниже конфигурация EIGRP обоих маршрутизаторов.
Все сети объявлены, и автоматическое суммирование отключено на обоих маршрутизаторах.
Суммирование было настроено на OFF2 и должно быть объявлено к OFF1.
К сожалению, ничего не видно на OFF1. Давайте проверим OFF2, чтобы посмотреть, что не так.
Когда дело доходит до устранения неполадок с сетью, вашими друзьями являются не Google или Яндекс, а команды Debug и show.
Странно, это единственная сеть, которую OFF2 объявляет.
Одно из золотых правил маршрутизации: вы не можете объявлять то, чего у вас нет. Очевидно, OFF2 знает только о сети 192.168.12.0 / 24.
Вот это ошибка! Кто-то выполнил команду отключения на интерфейсах обратной связи.
OFF2(config)#interface loopback 0
OFF2(config-if)#no shutdown
OFF2(config)#interface loopback 1
OFF2(config-if)#no shutdown
Включим интерфейсы.
Теперь мы видим, что суммирование объявляется.
Теперь мы видим суммирование в таблице маршрутизации OFF1- проблема решена!
Извлеченный урок: вы не можете объявлять то, чего у вас нет в таблице маршрутизации.
ВАЖНО. Последняя проблема может быть показаться простой, но есть важный момент, который вы не должны забывать: для объявления итогового маршрута в таблице маршрутизации объявляемого маршрутизатора должен быть указан хотя бы один префикс, попадающий в итоговый диапазон!
Case #5
Давайте посмотрим на другую топологию. На рисунке выше у нас есть концентратор Frame Relay и соответствующая топология. Каждый из OFF1 и OFF2 имеет интерфейс обратной связи, который мы будем объявлять в EIGRP. Вот соответствующая конфигурация всех маршрутизаторов:
CONC(config)#router eigrp 123
CONC(config-router)#no auto-summary
CONC(config-router)#network 192.168.123.0
OFF1(config-if)#router eigrp 123
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 192.168.123.0
OFF1(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config)#router eigrp 123
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 192.168.123.0
OFF2(config-router)#network 3.3.3.0 0.0.0.255
Видно, что все сети объявлены.
Наш концентратор-маршрутизатор видит сети из двух OFF-маршрутизаторов.
К сожалению, наши маршрутизаторы не видят ничего ...
Похоже, что маршрутизатор-концентратор не объявляет сети, которые он изучает с помощью OFF-маршрутизаторов. Давайте включим отладку, чтобы увидеть, что происходит.
CONC#clear ip eigrp 123 neighbors
Сбросим соседство EIGRP, чтобы ускорить процесс.
В отладке мы видим, что наш маршрутизатор-концентратор узнает о сети 2.2.2.0 / 24 и 3.3.3.0 / 24, но объявляет только сеть 192.168.123.0 / 24 для OFF-маршрутизаторов. Разделение горизонта не позволяет размещать объявление от одного маршрутизатора на другой.
CONC(config)#interface serial 0/0
CONC(config-if)#no ip split-horizon eigrp 123
Давайте отключим разделение горизонта на последовательном интерфейсе маршрутизатора-концентратора.
Теперь мы видим, что маршрутизатор-концентратор объявляет все сети.
OFF-маршрутизаторы теперь могут узнавать о сетях друг друга, поскольку split horizon отключено. Это хорошо, но это еще не все.
Извлеченный урок: RIP и EIGRP являются протоколами маршрутизации на расстоянии и используют split horizon. Split horizon предотвращает объявление префикса вне интерфейса, на котором мы его узнали.
Хотя сети отображаются в таблицах маршрутизации мы не можем пропинговать от одного OFF-маршрутизатора к другому. Это не проблема EIGRP, но она связана с Frame Relay. Мы должны это исправить.
Когда OFF1 отправляет IP-пакет на OFF2, IP-пакет выглядит следующим образом:
Давайте пока подумаем, как роутер, и посмотрим, что здесь происходит. Сначала нам нужно проверить, знает ли OFF1, куда отправить 3.3.3.3:
Существует запись для 3.3.3.3, а IP-адрес следующего перехода - 192.168.123.1 (маршрутизатор-концентратор). Можем ли мы достичь 192.168.123.1?
Нет проблем, кажется, OFF1 может пересылать пакеты, предназначенные для сети 3.3.3.0/24. Давайте перейдем к маршрутизатору CONC.
У маршрутизатора-концентратора нет проблем с отправкой трафика в сеть 3.3.3.0 / 24, поэтому на данный момент мы можем сделать вывод, что проблема должна быть в маршрутизаторе OFF2.
Это IP-пакет, который получает маршрутизатор OFF2, и когда он отвечает, он создает новый IP-пакет, который выглядит следующим образом:
Способен ли OFF2 достигать IP-адрес 192.168.123.2 Давайте узнаем!
Теперь мы знаем проблему ... OFF2 не может достичь IP-адреса 192.168.123.2
Если мы посмотрим на таблицу маршрутизации OFF2, то увидим, что сеть 192.168.123.0 / 24 подключена напрямую. С точки зрения третьего уровня у нас нет никаких проблем. Пришло время перейти вниз по модели OSI и проверить уровень 2 ... или, может быть, между уровнем 2 и 3.
Frame Relay использует Inverse ARP для привязки уровня 2 (DLCI) к уровню 3 (IP-адрес). Вы можете видеть, что нет сопоставления для IP-адреса 192.168.123.2.
OFF2(config)#int s0/0
OFF2(config-if)#frame-relay map ip 192.168.123.2 301
Давайте frame-relay map сами.
Теперь роутер OFF2 знает, как связаться с роутером OFF1
Наконец, маршрутизатор OFF1 может пропинговать интерфейс обратной связи маршрутизатора OFF2. Когда мы пытаемся пропинговать от маршрутизатора OFF2 к интерфейсу обратной связи маршрутизатора OFF1, у нас возникает та же проблема, поэтому мы также добавим туда оператор frame-relay map:
OFF1(config)#int s0/0
OFF1(config-if)#frame-relay map ip 192.168.123.3 201
Теперь у нас есть extra frame-relay map на маршрутизаторе OFF1.
И наш пинг проходит!
В сегодняшней статье поговорим об одном очень полезном инструменте Asterisk, который называется Call Flow. Данный инструмент позволяет управлять отправкой вызовов на основании положения переключателя. Переключатель может находиться в режиме Normal и Override. По сути, данный функционал является чем-то наподобие тумблера. Когда он в положении “включено”, входящие звонки будут отправляться по одному назначению, когда “выключено”, по другому. Например, в рабочие часы, необходимо настроить отправку входящих звонков на специальную ринг-группу, а в нерабочие – на IVR. С такой задачей поможет справиться модуль Time Conditions. Но если компания не имеет чётко определенного рабочего времени, то данный модуль уже не поможет, поскольку он переключает режим обработки вызовов автоматически в определенно заданное время.
/p>
С помощью Call Flow переключить “тумблер” можно в любое время и нужный режим обработки вызовов сохранится до тех пор, пока не будет изменен вручную. Для переключения режимов в Call Flow предусмотрены специальные коды (feature code). Существует 100 кодов (0-99), каждый из которых может включать определенный режим обработки вызовов. Чтобы использовать Call Flow нужно ввести специальный индекс ( 0-99) и дополнить его специальным кодом -28. Например, если индекс– 1, то feature code, включающий Call Flow будет *281.
Call Flow Control
Рассмотрим модуль Call Flow Control на примере FreePBX 13. Для того, чтобы открыть панель управления модулем, переходим по следующему пути Applications -> Call Flow.
По умолчанию, никаких записей нет. Жмём кнопку Add и перед нами открывается панель добавления нового переключателя.
Рассмотрим основные параметры, которые нужно настроить:
Call Flow Toggle Feature Code Index – Индекс переключателя. Как было сказано ранее, каждый feature code модуля Call Flow начинается с *28. Индекс это последняя часть кода, который может иметь значения от 0 до 99. Если вы выбрали 1 в качестве индекса, то код будет *281, если 78, то *2878 и так далее.
Description – Описание помогает быстро идентифицировать нужный переключатель среди остальных в списке.
Current Mode – Текущий режим. Выбор начального состояния переключателя Normal (Green/BLF off) или Override (Red/BLF on). Позднее эти кнопки (в дополнение к feature code’у) можно использовать для изменения режима.
Normal (Green/BLF off) - Эта настройка говорит о том, что звонки отправляются по стандартному назначению. Если на телефоне есть BLF, запрограммированный под данный feature code, то в данном состоянии лампочка будет гореть зеленым или не гореть вообще.
Override (Red/BLF on) – Эта настройка, говорит о том, что звонки отправляются по другому (нестандартному) назначению. Если на телефоне есть BLF запрограммированный под данный feature code, то в данном состоянии лампочка будет гореть красным.
Recording for Normal Mode – Позволяет настроить запись, которая будет проигрываться при переключении в нормальный режим. По умолчанию, сначала будет гудок (beep), а затем объявление о том, что feature code деактивирован. Вы можете записать собственное объявление при помощи модуля System Recordings
Optional Password – Опционально можно настроить специальный пароль для использования данного feature code’а. Пользователь, желающий воспользоваться кодом, должен будет сначала ввести пароль на своём телефоне.
Normal Flow Destination – Назначение, куда должны отправляться входящие звонки, когда переключатель находится в режиме Normal (Green/BLF off). Это может быть любое назначение на PBX, как то внутренний номер, IVR, ринг группа и т.д.
Override Flow – Это назначение, куда должны отправляться вызову, когда переключатель находится в режиме Override (Red/BLF on). Это может быть любое назначение на PBX, как то внутренний номер, IVR, ринг группа и т.д.
На примере ниже мы создали переключатель, который в нормальном режиме отправляет все звонки на IVR, а когда включен – на Announcement, который уведомит абонентов о том, что компания не работает. Для использования данного feature code’а, необходимо ввести на телефоне *2852