пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Протокол Spanning Tree (STP) обеспечивает отсутствие петель в топологии любой сети. Помимо предотвращения петель, STP изолирует угрозу от широковещательного шторма в сетях на втором уровне модели OSI (L2). Разберемся в терминах:
Какие бывают порты?
Можно смело выделить 3 вида портов в рамках протокола Spanning Tree. А именно:
Корневой порт (root port)
Выделенный порт (designated port)
Блокированный (альтернативный порт)
Статусы портов
Порт коммутатора может находиться в различных статусах, в зависимости от результата сходимости Spanning Tree:
Блокирован - как видно из названия, данный порт находится в статусе блокировки. Это означает, что порт не участвует в приеме и пересылке фреймов. Все BPDU сообщения от соседних коммутаторов исключаются.
BPDU (Bridge Protocol Data Unit) это фреймы, необходимые для обмена сообщениями между коммутаторами для выбора корневого (root) устройства в рамках механизма протокола STP (Spanning Tree Protocol).
Слушает – коммутатор все еще не участвует в процессе передачи фреймов с данными, но получает и отправляет сообщения BPDU.
Учится – в данном состоянии порт начинает фиксировать MAC – адреса устройств.
Пересылка – в состоянии пересылки, коммутатор может отправлять и принимать фреймы BPDU параллельно с заполнением таблицы MAC - адресов.
Выключен – порт выключен администратором.
Этапы протокола STP
Выбор «корневого» (root) коммутатора.
Выбор «корневого» (root) порта.
Назначение «выделенного» (designated) порта.
Блокировка остальных портов в рамках алгоритма STP.
Выбор корневого коммутатора
Коммутатор с наименьшим идентификатором (ID) выбирается как корневое устройство. Идентификатор коммутатора (switch ID) состоит из следующих компонентов: .
Номер приоритета .
MAC – адрес коммутатора
Например: 24577.00:00:00:00:00:01 / Приоритет. MAC – адрес
В процессе выбора корневого коммутатора, первым делом сравнивается приоритет. Если у двух коммутаторов одинаковых приоритет, то выбор базируется на MAC – адресе устройства.
Выбор корневого порта
Корневой порт выбирается на основании наименьшей «стоимости» пути к корневому коммутатору. Стоимость пути выражается из стоимости линков, ведущих к корневому коммутатору.
Важно отметить:
Корневые порты назначаются только на не корневых коммутаторах.
Один не корневой коммутатор может иметь только один корневой порт.
Выбор назначенного порта
Порт коммутатора, который имеет кратчайший путь к корневому коммутатору - называется «назначенным».
Каждый сегмент (путь) имеет свой назначенный порт.
Назначенные порты определяются на всех коммутаторах (корневых и нет).
Если два порта имеют одинаковую стоимость, сначала учитывается идентификатор устройства (Bridge ID), а затем идентификатор порта (Port ID).
Все остальные порты переходят в альтернативный статус и блокируются.
Пример
До запуска алгоритма Spanning Tree:
Выбор портов
Финальная топология
Скажите, вам было бы удобно, если бы до вас всегда можно было бы дозвониться по одному телефонному номеру? Всего один звонок заставит звонить офисный телефон посреди дня, мобильный посреди обеда и домашний посреди вечера. Для этого существует функция Single Number Reach (SNR) в Cisco CME (CUCME). Она позволяет добавить дополнительное устройство к “родительскому” номеру. Например, вы можете связать свой мобильный телефон с рабочим. Когда пойдет звонок на рабочий номер, то зазвонит телефон в офисе, а через заранее определенный интервал одновременно начнет звонить и мобильный. Если ни там, ни там не примут звонок, то CME переведет звонок на корпоративную голосовую почту.
/p>
Single Number Reach в CME по сути является облегченной версией функции Mobile Connect в CUCM, которая позволяет пользователю заставить звонить несколько устройств одновременно.
В дополнение к функции одновременного вызова Single Number Reach позволяет делать пользователю трансфер посреди звонка. Например, если вы начали разговор сидя за своим столом используя Cisco VoIP телефон, но потом вспомнили что опаздываете на запланированную видеоконференцию, то просто нажмите кнопку Mobility на стационарном телефоне и CME переведет вызов на мобильный телефон, как было настроено предварительно. Также можно всегда вернуть вызов обратно, нажав клавишу Resume.
Использование Single Number Reach может использовать дополнительные голосовые соединительные линии в PSTN. Функция, позволяющая переместить вызов между офисным и мобильным телефоном, доступна только потому, что CME постоянно поддерживает вызов. Например, если пользователь получил вызов на своем настольном телефоне, а затем нажал кнопку Mobility, чтобы отправить его на свой мобильный телефон, то будет задействовано две соединительные линии PSTN: одна для входящего вызова на офисный телефон и одна для исходящего вызова на мобильный телефон.
Настройка Single Number Reach
Для настройки этой функции можно использовать как командную строку, так и Cisco Configuration Professional (CCP) . Если используется CCP, то нужно перейти в меню Unified Communications → Users, Phones, and Extensions → Extensions и выбрать номер, на котором нужно настроить Single Number Reach. Нажимаем на Edit, переходим во вкладку Advanced и выбираем пункт меню Single Number Reach.
Здесь есть следующие опции:
Enable SNR for this extension – галочка включает функцию и позволяет настроить следующие поля
Remote Number – в этом поле нужно указать удаленный номер, на который CME должен перевести вызов, после определенного времени. Номер нужно вводить в соответствии с вашим диалпланом (например, если у вас выход в город через 9, то и здесь нужно указать девятку перед номером)
Ring remote number after – сколько секунд CME должен ждать перед тем перевести звонок на удаленный номер, указанный в предыдущем поле
Timeout – сколько секунд CME должен ждать, прежде чем считать звонок неотвеченным
Forward unanswered calls to – это опциональное поле, в котором можно указать, куда направлять неотвеченные звонки
При конфигурации через CLI используется такой синтаксис:
CME(config)#ephone-dn 2 dual-line
CME(config-ephone-dn)# snr 84996491913 delay 10 timeout 25 cfwd-noan 1101
CME(config-ephone-dn)# mobility
Тут snr – номер на который будет переведен звонок, delay – время до перевода, timeout – через сколько звонок будет считаться неотвеченным и cfwd-noan – куда будет направлен неотвеченный вызов. Функцию Mobility, которая позволяет делать транфер во время активного разговора, можно настроить отдельно от SNR.
Существует множество различных решений для управления Asterisk, основой которых, является FreePBX. К ним относятся - Elastix, PBX in a Flash (PIAF), Trixbox, AsteriskNOW и FreePBX Distro. Однако, с момента первого релиза FreePBX многое изменилось и большинство перечисленных проектов по-просту перестали существовать. Trixbox перестал поддерживать открытое ПО и переориентировался на коммерческую редакцию Trixbox Pro. Elastix и PIAF вообще дружно сменили свой движок с Asterisk на 3CX и для этих продуктов обновлений также больше нет. Кроме того, есть компании, которые до сих пор используют старые не поддерживаемые версии FreePBX и ежедневно испытывают трудности с их работой, а также те, кто установил FreePBX вручную на не поддерживаемые операционные системы.
Единственный продукт, который до сих пор обновляется и поддерживается разработчиком - это сам проект FreePBX и FreePBX Distro. Принимая это во внимание, разработчики FreePBX создали решение, которое позволяет сделать миграцию любой системы на базе FreePBX, (начиная с версии 2.9 до и включая версию 14) на свеженькую FreePBX Distro на базе ОС SNG 7, со всеми настройками и конфигурацией!
Итак, можно мигрировать с:
Elastix;
PBX in A Flash;
AsteriskNOW;
вручную установленного FreePBX (в том числе установленного на не поддерживаемой ОС);
FreePBX Distro
При этом система, с которой производится миграция не требует остановки эксплуатации или перезагрузки, так как инструмент всего лишь считывает конфигурацию с системы "донора" на свежую систему FreePBX Distro.
Как это работает:
Вам нужно будет установить свежую версию свежую версию FreePBX Distro , на которую будет происходить миграция и активировать её;
Запустить на новом сервере с FreePBX Distro скрипт конвертации командой: curl -s https://convert.freepbx.org | bash
Этой командой сервер запросит место (слот) в очереди на конвертацию. Когда слот будет успешно занят сгенерируется ключ, вида 2beb181b-14ed-4f56-a86b-f6e564ba6c43;
После этого, нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ;
Конвертер извлечёт необходимые данные с донора и загрузит их на новый сервер. Этот процесс не окажет никого влияния на донора, не внесёт на нем никаких изменений и не потребует выключения;
Скрипт также будет пробовать стянуть с донора всякие кастомные данные, такие как пользовательские голосовые файлы и данные провиженинга;
Все транки на новом сервере будут выключены, чтобы избежать конфликта с зарегистрированными линиями к провайдеру на старом сервере.
О том, как установить FreePBX читайте в нашей статье
Какие данные будут перенесены на новый сервер:
Внутренние номера (Extensions);
Маршруты (Inbound/Outbound Routes);
Линии к провайдеру (Trunks);
Музыка на ожидании (MoH);
Голосовые меню (IVR);
Группы вызова (Ring Groups);
Очереди (Queues);
Любые другие настройки, являющиеся стандартной частью FreePBX;
Звуковые файлы, включая: загруженную пользователем музыку на ожидании (MoH), записи голосовой почты и приветствия для голосовой почты, а также системные записи (System Recordings)
Какие данные не будут перенесены на новый сервер:
История звонков, то есть Call Data Report (CDR) и таблица Call Event Log (CEL);
Вы можете самостоятельно перенести эти данные на новый сервер, экспортируя их с помощью 'mysqldump' или аналогичной утилиты. Эти данные могут быть очень тяжёлыми, поэтому пользователь сам должен позаботиться об их переносе.
Настройки факса;
Эта часть претерпела огромные изменения с момента первого релиза FreePBX, поэтому придется самостоятельно перенастроить почты пользователей, которым нужен функционал факса.
Кастомные изменения конфигурационных файлов;
То есть всё, что было изменено в файлах вида *_custom.conf, например /etc/asterisk/extensions_custom.conf. Если у вас есть такие настройки, то переносить их на новый сервер нужно будет вручную.
Настройки не FreePBXовых модулей;
Ну например Elastix Call Center Module, Queue Metrics и остальные модули, которые не являются стандартными для FreePBX.
В общем и целом, звучит неплохо, правда? Мы можем безболезненно перенести большинство необходимых данных с неподдерживаемой системы и продолжить работу на новой, получая все актуальные обновления. Процесс миграции не представляется чем-то сверх сложным, так что давайте попробуем?
Процесс миграции
Итак, первое с чего нужно начать - это подготовка нового сервера с FreePBX Distro. Важно устанавливать именно 64-битную версию, поскольку 32-битная больше не поддерживается.
О том как установить FreePBX Distro подробно читайте в нашей статье.
Как только FreePBX Distro будет установлен, его необходимо активировать. Активация требуется для того чтобы сгенерировать криптографический ключ для защиты ваших данных для передачи на сервер конвертации https://convert.freepbx.org.
Данные передаются в зашифрованном виде, чтобы исключить возможность их утечки в случае атаки типа Man-in-the-Middle.
Затем необходимо настроить NAT. FreePBX Distro имеет свой встроенный модуль Firewall, который автоматически настраивает параметры NAT и Firewall через специальный помощник при первом запуске FreePBX.
О том как настраивать Firewall читайте в нашей статье.
После того как сервер с чистым FreePBX Distro настроен, необходимо зарезервировать слот для конвертации.
Это делается с помощью специального скрипта: curl -s https://convert.freepbx.org | bash. Когда Вам предложат ввести reservation ID, просто нажмите 'Enter'.
По окончанию процесса резервации слота, будет сгенерирован уникальный код конвертации вида: 2beb181b-14ed-4f56-a86b-f6e564ba6c43. Его потом нужно будет ввести на доноре.
После этого, новый сервер будет ожидать ответа от донора. Не останавливайте скрипт, нужно чтобы на экране была надпись Waiting for Donor….
Теперь нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ;
Возвращаемся на сервер-донор (Elastix, PIAF и так) с которого мы хотим мигрировать и запускаем тот же самый скрипт: curl -s https://convert.freepbx.org | bash
Когда вас попросят ввести ID, введите то что было сгенерировано при запуске скрипта на новом FreePBX Distro.
Это запускает процедуру экспорта всех данных и настроек с сервера донора и создание сжатого, криптографически защищённого архива с этими данными для отправки на новый сервер.
В зависимости от того, насколько давно был развёрнут старый сервер, существует возможность неудачной обработки команды скрипта, поскольку сервер может не поддерживать обработку TLS сертификатов. Если после запуска скрипта ничего не происходит, попробуйте запустить команду с отключением верификации TLS сертификата: curl --insecure https://convert.freepbx.org | bash
Как только процесс завершится, новый сервер будет иметь все настройки и данные, которые были на сервере доноре. Вы получаете полностью рабочий сервер со свежей версией FreePBX Distro, которая будет получать актуальные обновления софта и безопасности со всеми настройками, которые были на старом сервере!