По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Выходим на новый уровень. Для изучения следующей темы вы уже должны хорошо понимать связующее дерево. Связующее дерево (Spanning Tree Protocol STP) — это важная тема. Есть много вещей, которые могут пойти не так, и в этой статье мы рассмотрим ряд инструментов, которые мы можем использовать для защиты нашей топологии связующего дерева.
Для профессионалов
PortFast: мы видели это в статье о spanning tree и rapid spanning tree. Он настроит порт доступа как пограничный порт, поэтому он переходит в режим forwarding немедленно.
BPDU Guard: это отключит (err-disable) интерфейс, который имеет настроенный PortFast, если он получает BPDU.
BPDUFilter: это будет подавлять BPDU на интерфейсах.
Root Guard: это предотвратит превращение соседнего коммутатора в корневой мост, даже если он имеет лучший идентификатор моста.
UplinkFast: мы видели это в статье о связующем дереве. Он улучшает время конвергенции.
BackboneFast: мы также видели это в статье о связующем дереве. Оно улучшает время конвергенции, если у вас есть сбой косвенной связи.
UplinkFast и BackboneFast не требуются для rapid spanning tree, поскольку оно уже реализовано по умолчанию. Мы начнем с BPDUguard:
В топологии выше мы имеем идеально работающую топологию остовного дерева. По умолчанию связующее дерево будет отправлять и получать BPDU на всех интерфейсах. В нашем примере у нас есть компьютер, подключенный на интерфейсе fa0/2 коммутатора B. Есть кто-то, кто с враждебными намерениями мог бы запустить инструмент, который сгенерирует BPDU с превосходящим ID моста. Что же произойдет- так это то, что наши коммутаторы будут считать, что корневой мост теперь может быть достигнут через коммутатор B, и у нас будет повторный расчет связующего дерева. Звучит не очень хорошо, правда?
Можно поставить человека (хакера) в середине топологии для атаки так, чтобы никто не знал. Представьте себе, что хакер подключает свой компьютер к двум коммутаторам. Если хакер станет корневым мостом, то весь трафик от коммутатора А или коммутатора C к коммутатору В будет проходить через него. Он запустит Wireshark и подождет, пока произойдет чудо.
BPDUguard гарантирует, что, когда мы получаем BPDU на интерфейс, интерфейс перейдет в режим err-disable.
Чтобы продемонстрировать работу BPDUguard будем использовать два коммутатора. Настроем интерфейс fa0/16 коммутатора B так, что он перейдет в режим err-disable, если он получит BPDU от коммутатора C.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#spanning-tree bpduguard enable
Вот как вы включаете его в интерфейсе. Имейте в виду, что обычно вы никогда не будете делать это между коммутаторами. Вы должны настроить это на интерфейсах в режиме доступа, которые подключаются к компьютерам.
А-а... вот и наш интерфейс.
SwitchB(config-if)#no spanning-tree bpduguard
SwitchB(config-if)#shutdown
SwitchB(config-if)#no shutdown
Избавиться от BPDUguard можно используя команды shut/no shut, чтобы сделать интерфейс снова рабочим.
SwitchB(config)#spanning-tree portfast bpduguard
Вы также можете использовать команду spanning-tree portfast bpduguard. Это позволит глобально активировать BPDUguard на всех интерфейсах, которые имеют включенный portfast.
SwitchB(config)#spanning-tree portfast default
Portfast также может быть включен глобально для всех интерфейсов, работающих в режиме доступа.
Это полезная команда, позволяющая проверить свою конфигурацию. Вы видите, что portfast и BPDUGuard были включены глобально.
BPDUGuard переведет интерфейс в режим err-disable. Кроме того, можно фильтровать сообщения BPDU с помощью BPDUfilter. BPDUfilter может быть настроен глобально или на уровне интерфейса и есть разница:
Глобальный: если вы включите bpdufilter глобально, любой интерфейс с включенным portfast станет стандартным портом.
Интерфейс: если вы включите BPDUfilter на интерфейсе, он будет игнорировать входящие BPDU и не будет отправлять никаких BPDU.
Вы должны быть осторожны, когда включаете BPDUfilter на интерфейсах. Вы можете использовать его на интерфейсах в режиме доступа, которые подключаются к компьютерам, но убедитесь, что вы никогда не настраиваете его на интерфейсах, подключенных к другим коммутаторам. Если вы это сделаете, вы можете получить цикл.
Для демонстрации работы BPDUfilter мы будем снова использовать коммутатор B и коммутатор C.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#spanning-tree portfast trunk
SwitchB(config-if)#spanning-tree bpdufilter enable
Он перестанет посылать BPDU и будет игнорировать все, что будет получено.
SwitchB#debug spanning-tree bpdu
Вы не увидите никаких интересных сообщений, но если вы включите отладку BPDU, то заметите, что он больше не отправляет никаких BPDU. Если вы хотите, вы также можете включить отладку BPDU на коммутаторе C, и вы увидите, что нет ничего от коммутатора B.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#no spanning-tree bpdufilter enable
Давайте избавимся от команды BPDUfilter на уровне интерфейса.
SwitchB(config)#spanning-tree portfast bpdufilter default
Вы также можете использовать глобальную команду для BPDUfilter. Это позволит включить BPDUfilter на всех интерфейсах, которые имеют portfast.
Еще один вариант, с помощью которого мы можем защитить наше связующее дерево, - это использовать RootGuard. Проще говоря, RootGuard позаботится о том, чтобы вы не принимали определенный коммутатор в качестве корневого моста. BPDU отправляются и обрабатываются нормально, но, если коммутатор внезапно отправляет BPDU с идентификатором верхнего моста, вы не будете принимать его в качестве корневого моста. Обычно коммутатор D становится корневым мостом, потому что у него есть лучший идентификатор моста, к счастью, у нас есть RootGuard на коммутатое C, так что этого не произойдет!
Рассмотрим с вами конфигурацию с коммутатором B и коммутатором C.
SwitchB(config)#spanning-tree vlan 1 priority 4096
Давайте убедимся, что коммутатор C не является корневым мостом.
Вот как мы включаем RootGuard на интерфейсе.
SwitchB#debug spanning-tree events
Spanning Tree event debugging is on
Не забудьте включить отладку, если вы хотите увидеть события.
SwitchC(config)#spanning-tree vlan 1 priority 0
Давайте перенастроим коммутатор B, изменив приоритет на наименьшее возможное значение 0 на коммутаторе C. Он теперь должен стать корневым мостом.
Вот так коммутатор B не будет принимать коммутатор C в качестве корневого моста. Это заблокирует интерфейс для этой VLAN.
Вот еще одна полезная команда, чтобы проверить, работает ли RootGuard.
Связующее дерево становится все более безопасным с каждой минутой! Однако есть еще одна вещь, о которой мы должны подумать…
Если вы когда-либо использовали волоконные кабели, вы могли бы заметить, что существует другой разъем для передачи и приема трафика. Если один из кабелей (передающий или принимающий) выйдет из строя, мы получим однонаправленный сбой связи, и это может привести к петлям связующего дерева. Существует два протокола, которые могут решить эту проблему:
LoopGuard
UDLD
Давайте начнем с того, что внимательно рассмотрим, что произойдет, если у нас произойдет сбой однонаправленной связи.
Представьте себе, что между коммутаторами волоконно-оптические соединения. На самом деле имеется другой разъем для передачи и приема. Коммутатор C получает BPDU от коммутатора B, и в результате интерфейс стал альтернативным портом и находится в режиме блокировки.
Теперь что-то идет не так... transmit коннектор на коммутаторе B к коммутатору C был съеден мышами. В результате коммутатор C не получает никаких BPDU от коммутатора B, но он все еще может отправлять трафик для переключения между ними.
Поскольку коммутатор C больше не получает BPDU на свой альтернативный порт, он перейдет в forwarding режим. Теперь у нас есть one way loop (петля в один конец), как указано зеленой стрелкой.
Один из методов, который мы можем использовать для решения нашего однонаправленного сбоя связи — это настройка LoopGuard. Когда коммутатор отправляет, но не получает BPDU на интерфейсе, LoopGuard поместит интерфейс в состояние несогласованности цикла и заблокирует весь трафик!
Мы снова будем использовать эту топологию для демонстрации LoopGuard.
SwitchA(config)#spanning-tree loopguard default
SwitchB(config)#spanning-tree loopguard default
SwitchC(config)#spanning-tree loopguard default
Используйте команду spanning-tree loopguard по умолчанию, чтобы включить LoopGuard глобально
SwitchB(config)#interface fa0/16
SwitchB(config-if)#spanning-tree portfast trunk
SwitchB(config-if)#spanning-tree bpdufilter enable
В примере у нас нет никаких волоконных разъемов, поэтому мы не сможем создать однонаправленный сбой связи. Однако мы можем смоделировать его с помощью BPDUfilter на интерфейсе SwitchB fa0/16. Коммутатор C больше не будет получать никаких BPDU на свой альтернативный порт, что заставит его перейти в режим переадресации.
Обычно это вызвало бы петлю, но, к счастью, у нас есть настроенный LoopGuard. Вы можете увидеть это сообщение об ошибке, появляющееся в вашей консоли. Проблема решена!
SwitchC(config-if)#spanning-tree guard loop
Если вы не хотите настраивать LoopGuard глобально, вы т можете сделать это на уровне интерфейса.
Другой протокол, который мы можем использовать для борьбы с однонаправленными сбоями связи, называется UDLD (UniDirectional Link Detection). Этот протокол не является частью инструментария связующего дерева, но он помогает нам предотвратить циклы.
Проще говоря, UDLD — это протокол второго уровня, который работает как механизм keepalive. Вы посылаете приветственные сообщения, вы их получаете, и все прекрасно. Как только вы все еще посылаете приветственные сообщения, но больше их не получаете, вы понимаете, что что-то не так, и мы блокируем интерфейс.
Убедитесь, что вы отключили LoopGuard перед работой с UDLD. Мы будем использовать ту же топологию для демонстрации UDLD.
Существует несколько способов настройки UDLD. Вы можете сделать это глобально с помощью команды udld, но это активирует только UDLD для оптоволоконных линий связи! Существует два варианта для UDLD:
Normal (default)
Aggressive
Когда вы устанавливаете UDLD в нормальное состояние, он помечает порт как неопределенный, но не закрывает интерфейс, когда что-то не так. Это используется только для того, чтобы «информировать» вас, но это не предотвратит циклы.
Агрессивный - это лучшее решение, когда пропадает связь с соседом. Он будет посылать кадр UDLD 8 раз в секунду. Если сосед не отвечает, интерфейс будет переведен в режим errdisable.
SwitchB(config)#interface fa0/16
SwitchB(config-if)#udld port aggressive
SwitchC(config)#interface fa0/16
SwitchC(config-if)#udld port aggressive
Мы будем использовать коммутатор B и C, чтобы продемонстрировать UDLD. Будем использовать агрессивный режим, чтобы мы могли видеть, что интерфейс отключается, когда что-то не так.
Если вы хотите увидеть, что UDLD работает, вы можете попробовать выполнить отладку.
Теперь самое сложное будет имитировать однонаправленный сбой связи. LoopGuard был проще, потому что он был основан на BPDUs. UDLD запускает свой собственный протокол уровня 2, используя собственный MAC-адрес 0100.0ccc.сссс.
SwitchC(config)#mac access-list extended UDLD-FILTER
SwitchC(config-ext-macl)#deny any host 0100.0ccc.cccc
SwitchC(config-ext-macl)#permit any any
SwitchC(config-ext-macl)#exit
SwitchC(config)#interface fa0/16
SwitchC(config-if)#mac access-group UDLD-FILTER in
Это творческий способ создавать проблемы. При фильтрации MAC-адреса UDLD он будет думать, что существует сбой однонаправленной связи!
Вы увидите много отладочной информации, но конечным результатом будет то, что порт теперь находится в состоянии err-disable.
Вы можете проверить это с помощью команды show udld.
LoopGuard и UDLD решают одну и ту же проблему: однонаправленные сбои связи.
Они частично пересекаются, но есть ряд различий, вот общий обзор:
LoopGuardUDLDНастройкиГлобально/на портуГлобально (для оптики)/на портуVLAN?ДаНет, на портуАвтосохранениеДаДа, но вам нужно настроить errdisable timeout.Защита от сбоев STP из-за однонаправленных связейДа - нужно включить его на всех корневых и альтернативных портахДа - нужно включить его на всех интерфейсах.Защита от сбоев STP из-за сбоев программного обеспечения (нет отправки BPDU)ДаНетЗащита от неправильного подключения (коммутационный оптический приемопередающий разъем)НетДа
Есть еще одна последняя тема, которую хотелось бы объяснить, это не протокол связующего дерева, но речь идет о избыточных ссылках, поэтому я оставлю ее здесь. Это называется FlexLinks.
Вот в чем дело: при настройке FlexLinks у вас будет активный и резервный интерфейс. Мы настроим это на коммутаторе C:
Fa0/14 будет активным интерфейсом.
Fa0/16 будет интерфейс резервного копирования (этот блокируется!).
При настройке интерфейсов в качестве FlexLinks они не будут отправлять BPDU. Нет никакого способа обнаружить петли, потому что мы не запускаем на них связующее дерево. Всякий раз, когда наш активный интерфейс выходит из строя, резервный интерфейс заменяет его.
SwitchC(config)#interface fa0/14
SwitchC(config-if)#switchport backup interface fa0/16
Именно так мы делаем интерфейс fa0/16 резервной копией интерфейса fa0/14.
Вы можете видеть, что связующее дерево отключается для этих интерфейсов.
Проверьте нашу конфигурацию с помощью команды show interfaces switchport backup. Вот и все, что нужно было сделать. Это интересное решение, потому что нам больше не нужно связующее дерево. Ведь в любой момент времени активен только один интерфейс.
SwitchC(config)#interface f0/14
SwitchC(config-if)#shutdown
Давайте закроем активный интерфейс.
Вы можете видеть, что fa0/16 стал активным. Вот и все.
В данной статье рассмотрим процесс настройки интеграции ip-телефонии Asterisk и CRM Битрикс24 посредством модуля интеграции Itgrix (ранее называлось bx24asterisk). Перечислим возможности которые станут доступны после настройки данной интеграции:
В момент вызова открывается карточка клиента с именем и информацией о текущих сделках с этим клиентом.
Автоматически создается лид для неизвестного номера.
Для лида или контакта в CRM создается дело (оно же звонок), в нем можно прослушать запись разговора и увидеть его длительность.
Можно указать разные источники лидов для сквозной аналитики, в зависимости от того на какой из номеров телефона вам позвонили.
Автоматическое направление входящих вызовов на ответственного за клиента сотрудника.
Модуль состоит из двух частей: портальное приложение и серверное приложение, которое нужно установить на сервер с Asterisk.
Установка приложения в Битрикс
Заходим в меню Приложения, в поиске набираем Астериск, находим приложение Интеграция с Asterisk от компании Айтигро.
Кликаем по названию приложения, нажимаем Попробовать, соглашаемся с лицензионным соглашением и политикой конфиденциальности и нажимаем Установить.
После установки появится окно входа в настройки модуля, пока закроем его, ведь у нас еще нет серверной части приложения.
Заходим в Приложения - переходим на вкладку Установленные, находим там приложение Интеграция с Asterisk, нажимаем на кнопку Права доступа, выбираем раздел Другое, добавляем роль Все авторизованные пользователи, нажимаем Выбрать.
Установка приложения на сервер Asterisk.
Заходим на сервер по ssh, скачиваем скрипт установки модуля интеграции
wget 'https://bx24asterisk.ru/download/autoinstaller.sh'
Запускаем скрипт командой:
bash autoinstaller.sh
Cкрипт сам определит разрядность системы и установит подходящую версию. В конце установки нужно будет ввести логин и пароль для дальнейшего входа в web интерфейс с настройками модуля.
Дальнейшую установку можно производить из web интерфейса доступного по адресу https://ipasterisk:8078/config/master
При входе в web интерфейс нужно ввести логин и пароль который мы указали при установке приложения на сервер.
Выбираем язык
Данные для подключения к базе данных модуль найдет и подставит сам, нажимаем проверить
Warning в графе CEL означает что в таблицу CEL больше часа не записывались события звонков, такое может быть либо, если запись вCEL не осуществляется Asterisk’ом и нужно это настроить, либо просто давно не было звонков.
Далее подключаемся к Asterisk. Выбираем существующего пользователя либо создаем Нового. Через него модуль будет взаимодействовать с AMI Asterisk’а. Для нового - вводим пароль для пользователя bx24, модуль сам создаст пользователя. Проверяем.
Указываем где и в каком формате хранятся файлы записей
Указываем данные для подключения к порталу Битрикс24. Учетная запись должна обладать правами администратора в портале, через нее модуль будет работать с Битрикс24. Проверяем.
Далее описываем часть логики в Битрикс24
Указываем параметры логики CRM. В зависимости от того, в каком режиме у Вас работает CRM (с лидами или без).
Указываем как будем осуществлять звонки кликами по номеру в CRM:
Использовать Click2call сервер - команды для звонков будут передаваться на модуль через сервер разработчика;
Либо можно указать внешний ip адрес Asterisk (адрес роутера, за которым находится Asterisk) и пробросить порт 8077 до сервера с Asterisk. Команда из Битрикса на будет передавать на этот порт и обрабатываться модулем.
Сохраняем.
Попадаем на страницу с результатами всех проверок
Другая часть бизнес-логики
В результате должно получиться вот так: при входящем или исходящем звонке показывается карточка звонка:
После завершения звонка в лиде создается звонок. При пропущенном входящем звонке создается задача.
МТТ бизнес - виртуальная АТС от компании МТТ. Платформа позволяет обеспечить офис телефонной связью, организовать голосовую почту, маршрутизацию вызовов и прочие параметры. Сегодня мы поговорим о том, как интегрировать облачную ВАТС от МТТ Бизнес и IP – АТС Asterisk по протоколу SIP.
Настройки ЛК МТТ Бизнес
Приступаем к работе. Переходим по адресу https://business.mtt.ru/user/login:
Указываем наш логин и пароль. Входим в интерфейс управления ВАТС и переходим в раздел Настройки → Рабочие места → Создать рабочее место, как показано на скриншоте ниже:
Создаем рабочее место, как показано на скриншоте ниже:
Имя - придумайте имя для вашего пользователя;
Должность/Описание - какое – то описание. Можете написать что-то связанное с Asterisk, для очевидности и прозрачности дальнейшего администрирования;
SIP ID - отмечаем чекбокс, как показано на скриншоте;
Логин - сохраняем и записываем отдельно. Он нам пригодится :)
Пароль на оборудование - можете указать свой пароль, можете сгенерировать автоматически. Сохраните его – им мы тоже воспользуемся;
Кстати, если находитесь в поиске виртуальной АТС, то посмотрите в сторону МТТ Бизнес. Неплохое соотношение цена/качество :)
Попробовать ВАТС от МТТ Бизнес
Продолжаем экскурсию. Настроим маршрутизацию на нашего пользователя. Для этого, переходим в раздел Настройки → Входящая связь. Там, где указан ваш номер телефона, нажмите на зеленый плюсик («+»):
В появившемся окне выбираем На рабочее место:
В разделе настроек Переадресация на рабочее место нажимаем кнопку Выбрать:
Выбираем нашего юзера через чекбокс. В нашем случае мы создали PBXuser, как показали ранее:
Когда выбрали пользователя, нажимаем Сохранить:
В итоге работы, у вас должно получиться вот так:
Большая часть настроек позади. Приступаем к конфигурации на стороне Asterisk. Настройки выполним через FreePBX.
Настройки Asterisk (FreePBX)
Классика. Нам нужно сделать SIP – транк, а потом настроить маршрутизацию. Начнем с SIP – транка. Переходим в раздел Connectivity → Trunks. Далее нажимаем Add Trunk → Add Chan_sip trunk.
Что тут нужно сделать:
Trunk name - имя транка. Как вам имя mtt? :);
Outbound CallerID - номер телефона, который у вас прикручен к ВАТС МТТ Бизнес. То есть тот, на который звонят клиенты;
Тут все. Переходим во вкладку sip Setting, заполняем секцию Outgoing:
username=Логин
type=peer
secret=Пароль на оборудование
qualify=3000
nat=yes
insecure=invite,port
host=login.mtt.ru
dtmfmode=rfc2833
disallow=all
allow=alaw,ulaw
Переключитесь на вкладку Incoming и там в поле Register String укажите следующую конструкцию:
логин:пароль_на_оборудование@login.mtt.ru/ваш_номер
Сохраняем. Теперь нужно настроить только исходящую и входящую маршрутизацию. О том, как это сделать, можете прочитать в статье по ссылке ниже:
Настройка маршрутизации вызовов