По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Раньше, когда хабы еще находили применение в архитектуре сетей, анализировать трафик было очень просто. Достаточно было подключить компьютер со специальным ПО к одному из портов хаба и мы получали каждый пакет, передающийся по сети. Теперь, когда хабы не используются, а коммутаторы отправляют пакеты только на определенный порт, анализ трафика усложнился. Однако, большинство вендоров уже давно решили эту проблему, разработав механизмы “зеркалирования” трафика. Примерами таких механизмов являются SPAN(Switch Port Analyzer) и RSPAN (Remote Switch Port Analyzer), которые используются в оборудовании Cisco Systems. Не стоит путать SPAN/RSPAN с STP (Spanning Tree Protocol) и RSTP (Rapid Spanning Tree Protocol). Несмотря на то, что оба эти протокола работают на канальном уровне модели TCP/IP, служат они совершенно разным целям. Технологии “зеркалирования” трафика, к которым относятся SPAN и RSPAN, позволяют настроить коммутатор так, чтобы все пакеты, приходящие на один порт или группу портов коммутатора, дублировались на другом, с целью их дальнейшего анализа и мониторинга. Нет времени объяснять! Торопитесь? Нет времени читать матчасть? Прыгайте по ссылке ниже, тут настройка! Пример настройки Теория Как можно догадаться, функциональность SPAN’а ограничена пределами только одного устройства. Для того, что бы SPAN заработал необходимо настроить следующее: Источник (Source). То есть откуда брать трафик для анализа. Здесь можно указать порт коммутатора, работающий в режиме access, trunk и etherchannel, группу портов, т.е VLAN или L3 порт. Стоит отметить, что при указании в качестве источника определенного VLAN, будет дублироваться трафик со всех портов, которые в него входят. При добавлении или исключении порта из VLAN это сразу повлияет на SPAN. Получатель (Destination). Здесь указывается тот порт, куда будет “зеркалироваться” трафик. Стоит отметить, что по умолчанию будет дублироваться весь трафик, который проходит через источник. Однако, можно сконфигурировать SPAN так, чтобы отслеживались только входящие или исходящие пакеты. Пример коммутатора с настроенным SPAN приведен ниже: Как видно из рисунка, SPAN может отслеживать только трафик проходящий через коммутатор, на котором он настроен непосредственно. Remote SPAN (RSPAN) же позволяет производить мониторинг трафика на физически удаленных портах, через сеть коммутаторов. Источником трафика при настройке RSPAN являются source порты, входящие в специальный RSPAN VLAN, который задается специально для каждой RSPAN – сессии. Фреймы, передающиеся в этой сессии затем, проходят процедуру тегирования по протоколу 802.1q для передачи через другие устройства, находящиеся в сети. Добравшись до коммутатора, содержащего destination порт для данной RSPAN - сессии, трафик просто зеркалируется на указанный destination порт. Ниже приведен типовой пример сети с настроенным RSPAN: При настройке SPAN/RSPAN должны соблюдаться следующие условия: На одном коммутаторе может быть максимально сконфигурировано 64 destination порта Source порт не может быть destination портом и наоборот Для каждой SPAN/RSPAN – сессии может быть только один порт destination При объявлении порта как destination, он может только принимать “зеркалированный” трафик, остальные функции канального уровня становятся для него недоступными При объявлении порта, работающего в режиме switchport trunk, как source порта, трафик всех VLAN’ов, проходящих через данный порт будет отслеживаться Если в качестве источника указан VLAN, то трафик из другого VLAN’а, настроенного на коммутаторе не попадет в SPAN По умолчанию на destination порт не отслеживается и не передается трафик следующих протоколов, работающих на канальном уровне: CDP (Cisco Discovery Protocol), STP (Spanning Tree Protocol), (VTP) VLAN Trunking Protocol, (DTP) Dynamic Trunk Protocol и (PAgP) Port Aggregation Protocol
img
Мы подумали, а почему бы не консолидировать все знания по Cisco VoIP продуктам и их настройке в единый документ? Добавить в них советы, пошаговые руководства, полезные хинты и просто прожитый опыт наших инженеров? Так на свет родилось руководство администратора CUCM (Cisco Unified Communications Manager) и CME (Call Manager Express). Итак, встречайте - 317 страниц полезного чтива в формате PDF. Сохрани себе, поделись с коллегами. Получившееся руководство администратора Cisco UCM/CME можно получить по ссылке ниже: Скачать
img
Приходилось ли вам сталкиваться с задачами, которые не представляется возможным решить встроенными средствами FreePBX? Например, это может быть необходимость подключить TTS, настроить «кастомную» обработку вызова при звонке на конкретный внутренний номер и прочие задачи. Поискав в интернет, вы, возможно, уже находили готовые контексты обработки вызовов для решения ваших задач, а, возможно, вы самостоятельно создавали их с нуля. Так или иначе, появляется вопрос: как подключить собственный контексты, написанные в файле /etc/asterisk/extensions_custom.conf в FreePBX? Об это и поговорим. В нашем случае на помощь приходит модуль Custom Destinations. Назначения, созданные с помощью данного модуля, будут использовать специальные контексты, которые были созданы вручную и которые хранятся в конфигурационном файле /var/asterisk/extensions_custom.conf, а также эти назначения будут отображаться во всех других модулях, которые, так или иначе, участвуют в маршрутизации звонка, таких как: IVR, Queues, Announcement и прочие. Настройка модуля Перейдём к настройке. Чтобы попасть в модуль, с главной страницы переходим по следующему пути Admin –> Custom Destinations. Перед нами открывается следующее окно. Обратите внимание на предупреждение, оно сообщает нам, что для работы с модулем нам необходимо быть опытными и знающими пользователями :) Чтобы создать новое назначение, нажмите на кнопку Add Destination, откроется следующее окно Для каждого нового назначения необходимо указать следующие параметры: Target - Здесь необходимо указать ранее созданный контекст, на который нужно отправить абонента в формате [context],[exten],[priority]. Допустим, мы написали следующий контекст: [test_context] exten => s,1,Answer() exten => s,2,Playback(greetings) exten => s,3,Voicemail(100) exten => s,4,Hangup() Набор действий, которые будет выполнять система по данному контексту следующий: Отвечаем на звонок Озвучиваем файл greetings Отправляем на голосовую почту Завершаем вызов Таким образом, в поле Target можно записать следующее: test_context,s,1 Description - Простое описание, вновь создаваемого, назначения Notes - Здесь можно дать более развернутое описание, для чего и при каких условиях используется данное назначение Return - Возвращать ли звонок в родительский контекст, другими словами «обратно». Если выбрано Yes, то открывается список доступных направлений. Если No - звонок завершается Важно: при указании опции Return удостоверьтесь, что ваш «кастомный» контекст заканчивается командой Return Пример настройки Custom Destinations Для примера было создано следующая запись Здесь будет использоваться контекст test_context и после того, как все действия контекста будут завершены, модуль отправит звонок на IVR. Теперь можно использовать созданное нами назначение в других модулях, например Announcement Не забываем нажимать Submit и Apply Config
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59