По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Функция Call Waiting (CW) по умолчанию включена в FreePBX, что позволяет использовать так называемую «вторую линию», то есть ставить вызов на удержание и принимать параллельно ещё один входящий звонок на одном телефоне. Несмотря на то, что данная функция видна в разделе Applications модуля Module Admin, её настройку можно выполнить либо глобально, либо локально для каждого экстеншена. Подробнее расскажем об этом ниже.
Локальная настройка для экстеншенов и конечных пользователей
В первую очередь, данный параметр устанавливается отдельно в настройках каждого экстеншена, что отображается следующим образом:
Для отключения данной опции необходимо зайти в настройки экстеншена, далее выбрать вкладку Advanced, и в разделе Extension Options выставить Disable напротив опции Call Waiting.
Ещё одним способом управления данной опцией является использование сервисных кодов – по умолчанию установлены *70 на активацию и *71 на деактивацию данной опции. Удобство данного способа заключается в том, что каждый юзер может управлять данной настройкой на своём телефоне без обращения к администратору АТС.
Способы глобальной настройки Call Waiting
Первый способ является, по сути, автоматизированным способом настройки экстеншена – с помощью модуля Bulk Extensions – то есть вам необходимо выгрузить .csv файл со всеми экстеншенами, найти в файле нужную опцию (она обозначается как ENABLED) и просто стереть её (отсутствие значения = отключению опции).
Советуем пользовать функцией Текст по столбцам и дальнейшей обратной конвертацией файла в обычный .csv с помощью конвертера для наглядности и удобства.
Вторым способом является выключение CW Enabled by Default в положение No – но для этого необходимо пересоздавать экстеншены, так что данной опцией пользоваться не рекомендуется:
Настройка SNMP на коммутаторах и маршрутизаторах Cisco позволит вам мониторить состояние девайсов и сохранить свои нервы/время, в случаях, когда они начинают сбоить (игра на опережение). В целом, выглядит это так: сетевое устройство будет отправлять информацию о CPU, памяти, температуре, I/O и прочих на NMS (Network Management System) сервер. Изи – поехали.
Настройка
Подключаемся по SSH на наш сетевой узел и входим в режим конфигурации:
Кстати, о том, как настроить доступ по SSH к устройствам Cisco мы написали в статье.
en
conf t
Далее, необходимо создать группу (community), которая будет иметь права на чтение SNMP трапов (read – only). Назовем ее public:
SNMP – trap (трапы) – сообщения, которые отправит девайс, находящийся под мониторингом. Они нужны для того, чтобы информировать систему сбора трапов о наступлении различных событий.
snmp-server community public RO
Далее, аналогичным образом создаем частную группу (с правами на чтение и запись). Назовем ее private:
snmp-server community private RW
Сохраняем конфигурацию в NVRAM:
write memory
Важно! Проверьте сетевую связность между маршрутизатором и системой NMS, куда по плану роутер будет отправлять трапы.
Включаем трапы в Cisco IOS
Для передачи трапов в NMS, их необходимо включить. Сделать это не трудно – дайте в консоль девайса следующую команду (она включит все возможные виды трапов):
snmp-server enable traps
Если вам нужно конкретизировать, например, отправлять уведомления об окружении (температура, напряжение), или получать уведомление только о BGP, конкретизируйте это (полный список трапов можно найти на сайте вендора):
snmp-server enable traps envmon temperature
snmp-server enable traps bgp
Настройка NMS хоста
И напоследок, самое главное :) Укажем IP – адрес NMS – сервера, на который необходимо отправлять наши трапы. Опять же, если хотим отправлять все:
snmp-server host 192.168.0.2 public
Где, конечно, вместо 192.168.0.2 нужно указать адрес вашей NMS (это может быть Nagios, MRTG, Zabbix, Cacti и многие другие). Так же, вы можете указать конкретные события, которые нужно отправлять на этот NMS:
snmp-server host 192.168.0.2 public snmp bgp
Работа SR (Segment Routing) в MPLS и SR в IPv6 аналогична во всех отношениях, за исключением того, как передается и обрабатывается стек меток. Заголовки SR в IPv6 переносятся в поле метки потока, показанном на рисунке 8.
В реализации IPv6 SR стек меток SR переносится в заголовке маршрутизации заголовка пакета IPv6. Информация в этом заголовке предназначена специально для предоставления информации об узлах, через которые "этот пакет" должен проходить при маршрутизации по сети, поэтому он служит той же цели, что и стек меток SR. В случае реализации SR IPv6 каждая метка имеет длину 128 бит, поэтому в качестве SID можно использовать некоторый локальный IPv6-адрес.
Один интересный момент заключается в том, что спецификации IPv6 указывают, что заголовок IPv6 не должен изменяться маршрутизатором при обработке пакета (более подробную информацию см. В RFC8200). Вместо того, чтобы выталкивать (pop), проталкивать (push) и менять местами метки, SR IPv6 полагается на то, что каждый узел на пути имеет указатель на текущую метку в обрабатываемом стеке.
Метки маршрутизации сегментов сигнализации
SR технически является механизмом маршрутизации источника, потому что источник выбирает путь через сеть-хотя маршрутизация источника в SR может быть гораздо более свободной, чем традиционная маршрутизация источника. Для каждой метки в стеке существует два возможных способа обработки пакета узлом вдоль пути:
Метка содержит подробные инструкции о том, как пакет должен обрабатываться на этом устройстве: POP или CONTINUE сегмента (метки) и обработать пакет соответствующим образом.
Метка не содержит явных инструкций о том, как пакет должен обрабатываться на этом устройстве: использовать информацию о локальной маршрутизации для пересылки пакета и CONTINUE сегмента.
Ни в том, ни в другом случае узел обработки не должен знать обо всем пути для коммутации пакета: он либо просто следует по указанному пути метки, либо обрабатывает пакет на основе чисто локальной информации. Благодаря этой парадигме передача сигналов SR проста. Необходимы два типа сигнализации.
Локальный узел, префикс и SID смежности, назначенные узлу в сети, должны быть объявлены каждым узлом в сети. Эта передача сигналов в основном осуществляется в протоколов маршрутизации. Например, протокол от промежуточной системы к промежуточной системе (IS-IS) расширен черновым вариантом расширений (Intermediate System to Intermediate System- IS-IS) для Segment Routing1 для переноса SID префиксов с использованием значения длины подтипа (sub-TLV), как показано на рисунке 9.
Также для стандартизации предлагаются расширения к другим протоколам маршрутизации и уровня управления. Поскольку расчет пути в SR основан на источнике, нет необходимости переносить путь в протоколе распределенной маршрутизации. Единственная реальная необходимость - предоставить каждому узлу в сети информацию, необходимую для переноса информации об узле SR, префиксе и смежности.
В случае, когда пути SR вычисляются централизованным устройством или контроллером, должен быть способ объявить путь метки, который будет использоваться для достижения определенного назначения. Были предложены расширения для Border Gateway Protocol (BGP) в политике маршрутизации объявленных сегментов в BGP,2 и в протоколе Path Computation Element Protocol (PCEP) в расширениях PCEP для Segment Routing.3 Эти два вида объявления отделены друг от друга, поскольку единственным узлом в сети, который должен либо вычислить, либо наложить список сегментов, является головной узел туннеля или точка, где трафик входит в путь сегмента.