По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Классический стандарт связующего дерева работает нормально, но в настоящее время для современных сетей он слишком медленный 🐌
В настоящее время мы наблюдаем в наших сетях все больше и больше маршрутизации. Протоколы маршрутизации, такие как OSPF и EIGRP, намного быстрее адаптируются к изменениям в сети, чем spanning-tree. Чтобы не отставать от скорости этих протоколов маршрутизации, была создана еще одна разновидность связующего дерева... (rapid spanning tree) быстрое связующее дерево.
Rapid spanning tree - это не революция spanning tree, а его эволюция. Некоторые вещи были изменены для того, что бы ускорить процесс, но с точки зрения конфигурации - это то же самое, что классический spanning tree . Я называю оригинальное spanning tree "классическим spanning tree".
Азы Rapid spanning tree
Помните состояние портов spanning tree? У нас есть блокирующее, прослушивающее, обучающее и пересылающее состояние порта. Это первое различие между spanning tree и rapid spanning tree. Rapid spanning tree имеет только три состояния портов:
Отбрасывание;
Обучение;
Пересылка.
Вы уже знакомы с состоянием порта в режиме обучения и пересылки, но отбрасывание - это новое состояние порта. В основном он объединяет в себе блокировку и прослушивание состояния порта.
Вот хороший обзор с различными состояниями портов для spanning tree и rapid spanning tree. В таблице отображено состояние портов: активны ли они и узнают ли они MAC-адреса или нет.
Помните ли вы все остальные роли портов, которые есть у spanning tree? Давайте сделаем небольшой обзор, и будет показано отличие от rapid spanning tree.
Коммутатор с лучшим ID моста (priority + MAC -адрес) становится корневым мостом. Другие коммутаторы (non-root) должны найти кратчайший путь стоимости к корневому мосту. Это корневой порт. Здесь нет ничего нового, все это работает аналогично и в rapid spanning tree.
На каждом сегменте может быть только один назначенный порт, иначе мы получим петлю. Порт станет назначенным портом, если он сможет отправить лучший BPDU. Коммутатор А, как корневой мост, всегда будет иметь лучшие порты, поэтому все интерфейсы будут назначены. Интерфейс fa0/16 на коммутаторе B будет назначенным портом в моем примере, потому что он имеет лучший идентификатор моста, чем коммутатор C. Здесь все еще нет ничего нового по сравнению с классическим связующим деревом.
Коммутатор C получает лучшие BPDU на своем интерфейсе fa0/16 от коммутатора B, и таким образом он будет заблокирован. Это альтернативный порт, и это все еще то же самое, что и для rapid spanning tree.
Вот вам новый порт, взгляните на интерфейс fa0/17 коммутатора B. Он называется резервным портом и является новым для rapid spanning tree. Однако вы вряд ли увидите этот порт в производственной сети. Между коммутатором B и коммутатором C был добавлен хаб. Обычно (без промежуточного концентратора) оба fa0/16 и fa0/17 будут назначены портами. Из-за хаба интерфейсы fa0/16 и fa0/17 коммутатора B теперь находятся в одном домене коллизий. Fa0/16 будет выбран в качестве назначенного порта, а fa0/17 станет резервным портом для интерфейса fa0/16. Причина, по которой коммутатор B видит интерфейс fa0/17 в качестве резервного порта, заключается в том, что он получает свои собственные BPDU на интерфейсах fa0/16 и fa0/17 и понимает, что у него есть два соединения с одним и тем же сегментом. Если вы удалите хаб, то fa0/16 и fa0/17 будут назначены портами точно так же, как classic spanning tree.
BPDU отличается для rapid spanning tree. В classic spanning tree поле flags использовало только два бита:
Topology change.;
Topology change acknowledgment.;
Теперь используются все биты поля flags. Роль порта, который создает BPDU, будет добавлена с помощью поля port role, оно имеет следующие параметры:
Unknown;
Alternate / Backup port;
Root port;
Designated port.
Эта BPDU называется BPDUv2. Коммутаторы, работающие со старой версией spanning tree, проигнорируют эту новую версию BPDU. Если вам интересно ... rapid spanning tree и старое spanning tree совместимы! Rapid spanning tree способно работать с коммутаторами, работающими под управлением более старой версии spanning tree.
Что поменялось
BPDU теперь отправляются каждый hello time. Только корневой мост генерирует BPDU в classic spanning tree, и они ретранслировались non-root, если они получали его на свой корневой порт. Rapid spanning tree работает по-разному...все коммутаторы генерируют BPDU каждые две секунды (hello time). Это hello timeпо умолчанию, но вы можете его изменить.
classic spanning tree использует максимального время жизни (20 секунд) для BPDU, прежде чем они будут отброшены. Rapid spanning работает по-другому! BPDU теперь используются в качестве механизма поддержания активности, аналогичного тому, что используют протоколы маршрутизации, такие как OSPF или EIGRP. Если коммутатор пропускает три BPDU от соседнего коммутатора, он будет считать, что подключение к этому коммутатору было потеряно, и он немедленно удалит все MAC-адреса.
Rapid spanning tree будет принимать низшие BPDU. Classic spanning tree игнорирует их. Скорость перехода (время сходимости) является наиболее важной характеристикой rapid spanning tree. Classic spanning tree должно было пройти через состояние прослушивания и обучения, прежде чем оно переведет интерфейс в forwarding состояние, это занимает 30 секунд (таймер по умолчанию). Classic spanning было основано на таймерах.
Rapid spanning не использует таймеры, чтобы решить, может ли интерфейс перейти в forwarding состояние или нет. Для этого он будет использовать переговорный (negotiation) механизм. Чуть позже я покажу вам, как это работает.
Помните ли вы понятие portfast? Если мы включим portfast во время запуска classic spanning tree, оно пропустит состояние прослушивания и обучения и сразу же переведет интерфейс в forwarding состояние. Помимо перевода интерфейса в forwarding состояние, он также не будет генерировать изменения топологии, когда интерфейс переходит в состояние UP или DOWN. Мы все еще используем portfast для rapid spanning tree, но теперь он называется пограничным портом (edge port).
Rapid spanning tree может только очень быстро переводить интерфейсы в forwarding состояние на edge ports (portfast) или интерфейсы типа point-to-point. Он будет смотреть на link type, и есть только два ink types:
Point-to-point (full duplex);
Shared (half duplex).
Обычно мы используем коммутаторы, и все наши интерфейсы настроены как full duplex, rapid spanning tree видит эти интерфейсы как point-to-point. Если мы введем концентратор в нашу сеть, то у нас будет half duplex, который рассматривается как shared interface к rapid spanning-tree.
Позвольте мне описать механизм быстрой синхронизации spanning tree, используя рисунок выше. Коммутатор А сверху - это корневой мост. Коммутатор B, C и D- некорневые мосты (non-root).
Как только появится связь между коммутатором А и коммутатором B, их интерфейсы будут находиться в режиме блокировки. Коммутатор B получит BPDU от коммутатора A, и теперь будет происходить согласование, называемое синхронизацией.
После того, как коммутатор B получил BPDU от корневого моста, он немедленно блокирует все свои порты, не обозначенные в списке non-edge. Non-edge порты - это интерфейсы для подключения к другим коммутаторам, пока edge порты- интерфейсы, настроены как portfast. Как только коммутатор B блокирует свои non-edge порты, связь между коммутатором A и коммутатором B переходит в forwarding состояние.
Коммутатор B также выполнит операцию синхронизации как с коммутатором C, так и с коммутатором D, чтобы они могли быстро перейти в forwarding состояние.
Главное, что следует усвоить здесь, заключается в том, что rapid spanning tree использует этот механизм синхронизации вместо механизма "таймера", который использует classic spanning tree (прослушивание → обучение → forwarding).
Давайте увеличим масштаб механизма синхронизации rapid spanning tree, подробно рассмотрев коммутатор A и коммутатор B. Сначала интерфейсы будут заблокированы до тех пор, пока они не получат BPDU друг от друга. В этот момент коммутатор B поймет, что коммутатор A является корневым мостом, потому что он имеет лучшую информацию BPDU. Механизм синхронизации начнется, потому что коммутатор А установит proposal bit в поле flag BPDU.
Коммутатор B получает предложение от коммутатора A и понимает, что он должен что-то сделать. Он заблокирует все свои non-edge интерфейсы и запустит синхронизацию в направлении коммутатора C и коммутатора D.
Как только коммутатор B перевед свои интерфейсы в режим синхронизации, это позволит коммутатору А узнать об этом, отправив соответствующее соглашение.
Это соглашение является копией proposal BPDU, где proposal bit, был switched off, а agreement bit - switched on. Интерфейс fa0/14 на коммутаторе B теперь перейдет в режим forwarding.
Как только коммутатор A получит соглашение от коммутатора B, он немедленно переведет свой интерфейс fa0/14 в режим пересылки. А как насчет интерфейса fa0 / 16 и fa0 / 19 на коммутаторе B?
Точно такой же механизм синхронизации будет иметь место и сейчас на этих интерфейсах. Коммутатор B направит предложение по своим интерфейсам fa0/16 и fa0/19 в сторону коммутатора C и коммутатора D.
Коммутатор C и коммутатор D не имеют никаких других интерфейсов, поэтому они отправят соглашение обратно на коммутатор B.
Коммутатор B переведет свои интерфейсы fa0/16 и fa0/19 в режим forwarding, и на этом мы закончим. Этот механизм синхронизации - всего лишь пара сообщений, летающих туда-сюда, и очень быстро, это намного быстрее, чем механизм на основе таймера classic spanning tree!
Что еще нового в rapid spanning tree?
Есть еще три вещи:
UplinkFast;
Механизм изменения топологии;
Совместимость с классическим связующим деревом.
Когда вы настраиваете classic spanning tree, вы должны включить UplinkFast самостоятельно. Rapid spanning tree использует UpLinkFast по умолчанию, вам не нужно настраивать его самостоятельно. Когда коммутатор теряет свой корневой порт, он немедленно переводит свой альтернативный порт в forwarding.
Разница заключается в том, что classic spanning tree нуждалось в multicast кадрах для обновления таблиц MAC-адресов всех коммутаторов.
Нам это больше не нужно, потому что механизм изменения топологии для rapid spanning tree отличается. Так что же изменилось в механизме изменения топологии?
С classic spanning tree сбой связи вызвал бы изменение топологии. При использовании rapid spanning tree сбой связи не влияет на изменение топологии. Только non-edge интерфейсы (ведущие к другим коммутаторам), которые переходят в forwarding состояние, рассматриваются как изменение топологии. Как только коммутатор обнаружит изменение топологии это произойдет:
Он начнет изменение топологии при значении таймера, которое в два раза превышает hello time. Это будет сделано для всех назначенных non-edge и корневых портов.;
Он будет очищать MAC-адреса, которые изучаются на этих портах.;
До тех пор, пока происходит изменение топологии, во время активности таймера, он будет устанавливать бит изменения топологии в BPDU, которые отправляются из этих портов. BPDU также будет отправлен из своего корневого порта.;
Когда соседний коммутатор получит этот BPDU с установленным битом изменения топологии, произойдет следующее:
Он очистит все свои MAC-адреса на всех интерфейсах, кроме того, на котором он получил BPDU с включенным изменением топологии.;
Он запустит изменение топологии во время самого таймера и отправит BPDU на все назначенные порты и корневой порт, установив бит изменения топологии.;
Вместо того, чтобы отправлять изменения топологии вплоть до корневого моста, как это делает classic spanning tree, изменение топологии теперь быстро распространяется по всей сети.
И последнее, но не менее важное, давайте поговорим о совместимости. Rapid spanning tree и classic spanning tree совместимы. Однако, когда коммутатор, на котором работает Rapid spanning tree, связывается с коммутатором, на котором работает classic spanning tree, все функции скоростной передачи данных не будут работать!
В приведенном выше примере у меня есть три коммутатора. Между коммутатором A и коммутатором B мы запустим rapid spanning tree. Между коммутатором B и коммутатором C мы вернемся к classic spanning tree.
В Amocrm существует два вида воронок: Воронка продаж и Digital воронка. Обе они являются эффективными инструментами для отдела продаж. Основным элементом построения воронки являются этапы, по которым проходит лид перед тем, как совершить целевое действие.
/p>
В Amo можно создавать до 10 воронок, в каждой из которой можно настроить до 100 шагов.
Как создать воронку продаж в AmoCRM?
Технически начало построения воронки начинается с открытия вкладки «Сделки» . По умолчанию к редактированию предлагается воронка со стандартными шагами.
Далее можно создавать шаги, которые являются последовательностью этапов продаж. Некоторые из них могут заканчиваться неуспешным статусом, например, отказом клиента от покупки.
Самостоятельная настройка воронки продаж
Создатели AmoCRM рекомендует следовать следующим правилам при самостоятельной настройке воронки продаж:
Создавать шаги, которые являются этапами продаж
Разделять этапы по длительности
Разделять воронки по отделам
Называть этапом конкретное действие
Шаги, которые являются этапами продаж
Специалисты рекомендуют избегать этапов, которые не содержат шаги, приближающие лид к совершению покупки. Так же не создавайте этапы-напоминания. Конечно, существуют сценарии, в которых клиент не выходит на связь, после отправки заявки, или ему не подошли условия. В таком случае следует создать отдельную воронку, в которой будут существовать неуспешные этапы продаж. Это поможет составить более точную и дифференцированную статистику по продажам.
Разделять этапы по длительности
Самым лучшим вариантом является обозначение времени для каждого шага. Когда в одном этапе сделки сочетается конкретный срок и задание с неопределенной длительностью, высок риск того, что менеджер может забыть или даже «забить» на выполнение задачи. Если каждый этап имеет свой определенный дедлайн, система пришлет менеджеру напоминание, когда срок вот-вот подойдет к концу. Установить срок выполнения задачи можно в настройках Сделки. Выберите «Создать новую сделку» или «Редактировать» уже существующую.
Разделение воронки при работе нескольких отделов
Случается, что над одной заявкой может работать более одного отдела. Например, сначала клиент контактирует с колл-центром, потом с персональным менеджером по продажам, и в конце концов с финансовым и юридическим отделом, где заключается договор. В этой ситуации продуктивным способом разделить ответственных по шагам и отследить статистику по каждому отделу.
Работа со сделками
Сделки перемещаются по этапам воронки, с ними взаимодействуют менеджеры по продажам и другие ответственные, которые к ней прикреплены. Чтобы извлечь максимум пользы от каждого взаимодействия с клиентом, рекомендуется отредактировать поля карточки сделки в зависимости от специфики бизнеса. Это действие, как и редактор воронок, доступно только администратору системы.
Подключите веб-форму
В AmoCRM есть возможность подключения формы обратной связи с сайта прямо к системе. Это означает, что заявки с сайта будут автоматически поступать в воронку.
Периодические покупки
Это совершенно новый инструмент в AmoCRM, который позволяет работать с существующими клиентами, строить ожидания и гипотезы, когда они вновь обратятся в компанию. Для активации данного инструмента необходимо перейти в «Настройки» - «Общие настройки» , выбрать Периодические покупки и активировать их.
После этого система перенесет администратора в раздел «Покупатели» , где необходимо будет задать условия взаимодействия с постоянными клиентами, задачи и рекламные материалы. Amo будет периодически высылать промо материалы этим покупателям, стимулируя их на покупку.
Технология TTS (text-to-speech) служит для преобразования текстовой информации в голос. Проще говоря, вы пишите – система проговаривает. В системах телефонной связи такая технология может быть полезна, если необходимо произнести баланс клиента или для озвучивания прочих голосовых сообщений. О том, как настроить TTS в FreePBX 13 с помощью командной строки Asterisk расскажем в статье.
Встроенный TTS
В FreePBX предусмотрен встроенный движок для TTS, который носит название filte. Движок хорошо отрабатывает английскую речь, но не умеет работать с русской. Вкратце ознакомимся с его настройкой. Тут все достаточно тривиально, переходим в Applications -> Text to Speech
Name - дайте имя для TTS механизма
Text - укажите произносимый системой набор слов
Choose an Engine - выберите движок для воспроизведения. По умолчанию, единственным доступным является filte
Destination - куда будет отправлен звонок, после проговаривания фразы указанной в поле Text
На этом этапе система произнесет набор слов по-английски. Писать методом транслитерации – плохая идея. Движок конечно произнесет указанные слова, но это вряд ли можно будет отправить в «продакшн». Итак, как же бесплатно настроить русскоговорящий TTS в FreePBX? Легко, с помощью системы синтеза речи festival
Русский язык FreePBX Festival
Установку будем производить на примере последней сборки FreePBX Distro на базе CentOS 6. Переходим к установке. Скачиваем исходные файлы
cd /usr/src
wget http://www.cstr.ed.ac.uk/downloads/festival/2.1/speech_tools-2.1-release.tar.gz
wget http://www.cstr.ed.ac.uk/downloads/festival/2.1/festival-2.1-release.tar.gz
Распаковываем архивы и инсталлируем необходимые файлы
tar zxvf festival-2.1-release.tar.gz
tar zxvf speech_tools-2.1-release.tar.gz
cd speech_tools
./configure
make
make install
cd ..
cd festival
./configure
make
make install
Система может потребовать установить пакет ncurses-devel. Сделайте это с помощью команды yum install ncurses-devel
Создаем переменную PATH, которая описывает путь до исполняемых файлов в директории festival/bin/
export PATH=$PATH:/usr/src/festival/bin/
Создадим директорию для хранения русскоязычных файлов. Для этого, последовательно в директории festival/lib/ создадим папки /voices и /russian:
mkdir /usr/src/festival/lib/voices/
mkdir /usr/src/festival/lib/voices/russian/
Скачиваем русскоязычный бандл:
wget http://sourceforge.net/projects/festlang.berlios/files/msu_ru_nsh_clunits-0.5.tar.bz2
Далее, распаковываем скачанный архив в созданную директорию:
tar xjf msu_ru_nsh_clunits-0.5.tar.bz2 -C ./festival/lib/voices/russian
Открываем через редактор vim файл /usr/src/festival/lib/languages.scm
vim /usr/src/festival/lib/languages.scm
В самом начале файла вставляем следующие строки:
(define (language_russian)
"(language_russian)
Set up language parameters for Russian."
(set! male1 voice_msu_ru_nsh_clunits)
(male1)
(Parameter.set 'Language 'russian)
)
В файле находим строки указанные ниже:
(language_british_english))
((equal? language 'british_english)
После указанных выше строк, добавляем следующее:
(language_russian))
((equal? language 'russian)
Далее открываем файл /usr/src/festival/lib/siteinit.scm и в самый конец добавляем строку ниже:
(set! voice_default 'voice_msu_ru_nsh_clunits)
Создаем кэш – директорию. Для этого, скопируйте команду ниже:
mkdir /var/lib/asterisk/festivalcache/ && chown asterisk:asterisk /var/lib/asterisk/festivalcache/
Открываем файл /etc/asterisk/festival.conf и добавляем следующие строки:
[main]
host=localhost
port=1314
usecache=yes
cachedir=/var/lib/asterisk/festivalcache/ \созданный выше файл
festivalcommand=(tts_textasterisk "%s" 'file)(quit)
Запускаем сервер festival
festival --server
Если все успешно, то вы увидите строки ниже:
[pbx@localhost ~]#festival --server
server Fri Aug 12 13:00:32 2016 : Festival server started on port 1314
Приступаем к тестам. Открываем файл /etc/asterisk/extensions_custom.conf и создаем тестовый диал – план как указано ниже:
[festival]
exten => s,1,Answer
exten => s,n,Festival('Привет. Все. работает.')
exten => s,n,Hangup
Сохраняем изменения. Для того, чтобы настроить воспроизведение из графического интерфейса FreePBX мы воспользуемся модулем Custom Destinations. Для его настройки перейдите во вкладку Admin -> Custom Destinations . Нажимаем на кнопку Add Destination
Разберем каждую из опций:
Target - укажите здесь festival,s,1, согласно созданному ранее диал-плану. Синтаксис заполнения следующий - [имя_контекста],[экстеншен],[приоритет]
Description - описание создаваемого правила
Notes - заметки. Если вы создаете много подобных правил, советуем создавать подробные заметки, чтобы избежать дальнейшей путаницы.
Return - если ваш контекст заканчивается командой Return (команда возвращает вызов в родительский контекст), то в поле Destination укажите назначение для вызова после отработки TTS.
По окончанию настроек нажмите Submit и затем Apply Config.
Теперь необходимо настроить маршрутизацию на кастомный контекст, который мы только что создали в FreePBX. Например, можно настроить маршрутизацию из IVR меню по нажатию цифры 5 на телефоне, как указано ниже:
Звоним на IVR и нажимаем 5 и слышим синтезированный голос. Параллельно смотрим на запущенный через CLI сервер Festival:
client(1) Fri Aug 12 13:00:54 2016 : accepted from localhost
client(1) Fri Aug 12 13:01:04 2016 : disconnected
client(2) Fri Aug 12 13:01:20 2016 : accepted from localhost
client(2) Fri Aug 12 13:01:20 2016 : disconnected
Google TTS в FreePBX
Еще пару лет назад можно было бы легко воспользоваться Google TTS для синтеза речи. Для этого надо было добавить движок во вкладке Settings -> Text To Speech Engines и отредактировать файл /var/lib/asterisk/agi-bin/propolys-tts.agi. Но, к сожалению, Google начал использовать капчу, чем перекрыл автоматизированный и бесплатный доступ к своему сервису.
Дополнительно про настройку TTS от Festival вы можете прочитать здесь.