По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Ищете возможность анализировать сетевой трафик/отправлять его на систему записи телефонных разговоров? Изи. Коммутаторы Cisco (да и многие другие) дают возможность копировать пакеты с определенного порта или VLAN и отправлять эти данные на другой порт для последующего анализа (Wireshark, например).
Кстати, этот функционал полезен при использовании IDS (Intrusion Detection System) систем в целях безопасности. Мы уже рассказывали теоретические основы SPAN/RSPAN, поэтому, сегодняшняя статья будет посвящена практике настройке.
Про настройку SPAN
В рамках обычной SPAN сессии захват (копирование) сетевого трафика происходит с порта источника (source port) и отправляется на порт назначения (destination port). Обратите внимание на пример ниже: мы сделаем SPAN – сессию с порта fa 0/1 и отправим данные на порт fa 0/5:
Важно! SPAN – сессия может работать только в рамках одного коммутатора (одного устройства).
Конфигурация:
switch# configure terminal
switch(config)# monitor session 1 source interface fa0/1
switch(config)# monitor session 1 destination interface fa0/5
Просто, не правда ли? В рамках данной конфигурации весь трафик с порта fa 0/1 будет скопирован на порт fa 0/5.
Интереснее: пример RSPAN
Идем вперед. Более продвинутая реализация зеркалирования трафика это RSPAN (Remote SPAN). Эта фича позволяет вам зеркалировать трафик между различными устройствами (коммутаторами) по L2 через транковые порты. Копия трафика будет отправляться в удаленный VLAN между коммутаторами, пока не будет принята на коммутаторе назначения.
На самом деле, это легко. Давайте разберемся на примере: как показано на рисунке, мы хотим копировать трафик с коммутатора №1 (порт fa 0/1) и отправлять трафик на коммутатор №2 (порт fa 0/5). В примере показано прямое транковое подключение между коммутаторами по L2. Если в вашей сети имеется множество коммутаторов между устройствами источника и назначения – не проблема.
Конфигурация:
//Настройки на коммутаторе источнике
switch_source# config term
switch_source(config)# vlan 100 //Создаем Remote VLAN на первом коммутаторе (в который будем передавать данные с source порта)
switch_source(config-vlan)# remote span
switch_source(config-vlan)# exit
switch_source(config)# monitor session 10 source interface fa0/1
switch_source(config)# monitor session 10 destination remote vlan 100
//Настройки на коммутаторе получателе
switch_remote# config term
switch_remote(config)# vlan 100 //Создаем Remote VLAN на втором (удаленном) коммутаторе (в который будем передавать данные с source влана уже на порт назначения)
switch_remote(config-vlan)# remote span
switch_remote(config-vlan)# exit
switch_remote(config)# monitor session 11 source remote vlan 100
switch_remote(config)# monitor session 11 destination interface fa0/5
Таким образом, весь трафик с интерфейса fa 0/1 на локальном коммутаторе (источнике) будет отправлен в vlan 100, и, когда коммутатор получатель (remote) получит данные на 100 VLAN он отправит их на порт назначения fa 0/5. Такие дела.
Party Hard: разбираемся с ERSPAN
ERSPAN (Encapsulated Remote Switched Port Analyzer) - фича, которая используется для копирование трафика в L3 сетях. В основе работы механизма лежит GRE инкапсуляция.
Как показано ниже, между коммутатором источником и коммутатором получателем устанавливается GRE – туннель (между IP – адресами машин). Опять же, мы хотим отправить трафик с порт fa 0/1 на порт fa 0/5.
Конфигурация:
//Настройки на коммутаторе источнике
switch_source(config)# monitor session 1 type erspan-source
switch_source(config-mon-erspan-src)# source interface fa0/1
switch_source(config-mon-erspan-src)# destination
switch_source(config-mon-erspan-src-dst)# erspan-id 111 //Это значение должно быть одинаковым на всех устройствах
switch_source(config-mon-erspan-src-dst)# ip address 192.168.1.5 //IP - адрес коммутатора получателя
switch_source(config-mon-erspan-src-dst)# origin ip address 192.168.2.5 //IP - адрес коммутатора отправителя (источника)
//Настройки на коммутаторе получателе
switch_remote(config)# monitor session 1 type erspan-destination
switch_remote(config-mon-erspan-dst)# destination interface fa0/5
switch_remote(config-mon-erspan-dst)# source
switch_remote(config-mon-erspan-dst-src)# erspan-id 111
switch_remote(config-mon-erspan-dst-src)# ip address 192.168.1.5 //IP - адрес коммутатора получателя (назначения)
Траблшутинг
Мониторинг трафика в указанном VLAN:
monitor session 1 source vlan 13
Мониторинг входящего или только исходящего трафика:
monitor session 1 source vlan 13 rx/tx
Посмотреть конфигурацию сессии зеркалирования:
show monitor session 1
Двенадцатая часть тут.
Другая проблема, с которой сталкиваются решения мультиплексирования, - это возможность адресовать конкретный экземпляр службы, реализованной на нескольких хостах, используя один адрес. Рисунок 1 иллюстрирует это.
На рисунке 1 некоторые службы, S, должны быть спроектированы так, чтобы повысить их производительность. Для достижения этой цели была создана вторая копия службы, две копии которой называются S1 и S2. Эти две копии службы работают на двух серверах, M и N. Проблема, которую anycast пытается решить, заключается в следующем:
Как можно направить клиентов к наиболее оптимальному экземпляру сервиса?
Одним из способов решения этой проблемы является перенаправление всех клиентов на одно устройство и распределение нагрузки на серверы с помощью балансировщика нагрузки в зависимости от топологического расположения клиента, нагрузки на каждый сервер и других факторов. Однако это решение не всегда идеально. Например, что, если балансировщик нагрузки не может обработать все запросы на подключение, сгенерированные клиентами, которые хотят получить доступ к различным копиям службы? Какие сложности будут добавлены в сеть, чтобы балансировщик нагрузки мог отслеживать состояние различных копий службы?
Anycast решает эту проблему, присваивая один и тот же адрес каждой копии сервиса. В сети, показанной на рисунке 4, тогда M и N будут использовать один и тот же адрес, чтобы обеспечить достижимость для S1 и S2. M и N будут иметь разные адреса, назначенные и объявленные для обеспечения доступности для других служб, а также для самих устройств.
H и K, маршрутизаторы первого перехода за пределами M и N, будут объявлять этот же адрес в сети. Когда C и D получат два маршрута к одному и тому же пункту назначения, они выберут самый близкий маршрут с точки зрения метрик. В этом случае, если каждый канал в одной и той же сети настроен на одну и ту же метрику, то C будет направлять трафик, исходящий из A, и направленный на адрес службы, в направлении M. D, с другой стороны, будет направлять трафик, полученный из B и предназначен для адреса службы, к N. Что произойдет, если два экземпляра службы находятся на одинаковом расстоянии друг от друга? Маршрутизатор выберет один из двух путей, используя локальный алгоритм хеширования.
Anycast часто используется для крупномасштабных служб, которые должны масштабироваться путем предоставления большого количества серверов для поддержки одного сервиса. Например:
Большинство крупных серверов системы службы доменных имен (DNS) на самом деле представляют собой набор серверов, доступных через anycast адрес.
Многие крупномасштабные веб-сервисы, в частности социальные сети и поиск, где один сервис реализован на большом количестве периферийных устройств.
Службы кэширования контента часто используют anycast для распространения и обслуживания информации.
Правильно спроектированный anycast может обеспечить эффективную балансировку нагрузки, а также оптимальную производительность для служб.
В данной статье рассмотрим ещё один полезный модуль из базового функционала FreePBX 13 - Set CallerID. Данный модуль позволяет влиять на идентификатор вызывающего абонента (CID- СallerID) в рамках процесса установления вызова. Например, если у вас несколько провайдеров по-разному отдают CallerID, в данном модуле можно привести их к общему виду для корректного отображения в CDR или добавить к определенным входящим звонкам уникальный префикс.
Пошаговое видео
Настройка модуля Set CID
Перейдём к настройке. Традиционно, для всех примеров, будем использовать FreePBX версии 13. Для того, чтобы попасть в модуль Set CallerID, с главной страницы, переходим по следующему пути: Applications -> Set CallerID. По умолчанию, данная вкладка пустая, нажимаем на кнопку Add
Откроется следующее окно добавления нового CID, в котором необходимо заполнить следующие пункты.
Рассмотрим подробнее каждый из пунктов:
Description - Предлагается ввести описательное название нового CID, которое поможет определить его назначение. Например: “Sales CID”
CallerID Name - Здесь настраивается на что будет заменено имя звонящего (caller ID name). Если предполагается изменение текущего имени, то необходимо включить соответствующие переменные. Если же оставить данное поле пустым, то имя звонящего останется пустым.
CallerID Number - Здесь настраивается на что будет заменён номер звонящего (caller ID number). Если предполагается изменение текущего номера, то необходимо включить соответствующие переменные. Если же оставить данное поле пустым, то номер звонящего останется пустым.
Destination - Здесь выбирается назначение для продолжения звонка. Звонок будет перенаправлен по данному назначению с новыми именем и номером (CallerID Name/ Number)
Пример модификации Caller ID Name
Давайте рассмотрим несколько примеров, чтобы понять, как работает данный модуль, а заодно и принципы работы с переменными.
Допустим, мы хотим добавить некий префикс к номерам, которые маршрутизируются с нашего IVR. Мы знаем, что на нашем IVR настроен маршрут для соединения с отделом продаж по клавише “3” и хотим, чтобы у всех звонков, отправленных по данному маршруту был префикс “Sales” перед номером.
Для этого, сначала создаём новый шаблон в модуле.
В поле Description пишем “Sales CID”
В поле CallerID Name пишем “Sales:” перед ${CALLERID(name)}, это действие и добавляет необходимый префикс.
Поле CallerID Number оставляем без изменений
Наконец, в поле Destination, выбираем назначение для данного шаблона – внутренний номер менеджера по продажам (7771 Sales Manager)
Не забываем нажимать Submit и Apply Config
Далее, отправляемся в модуль IVR и настраиваем соответствующее правило.
Готово, теперь все абоненты, попавшие на IVR и нажавшие клавишу “3” на телефоне, попадут на менеджера по продажам, но их номера на дисплее телефона менеджера, будут иметь префикс “Sales”, так менеджер поймёт, что звонок поступил с IVR.
Если Вы хотите подробнее ознакомиться с возможностями модуля IVR, прочитайте нашу соответствующую статью о настройке модуля IVR во FreePBX 13.
Пример модификации Caller ID Number
Рассмотрим другой пример. Допустим, наш провайдер отдаёт нам callerID в формате 8ХХХХХХХХХХ. Но звонить в город мы должны через префикс “9”. Если нам придёт звонок с номера 8ХХХХХХХХХХ, мы должны будем сначала набрать “9”, чтобы дозвониться. Данную задачу можно решить с помощью модуля Set CallerID.
Создадим новый шаблон.
В поле Description пишем “Outbound Prefix 9”
Поле CallerID Name оставляем без изменений
В CallerID Number
Наконец, в поле Destination, выбираем назначение для данного шаблона, например ринг-группа - (4543 Managers)
Готово, теперь, при поступлении внешнего звонка на ринг-группу Managers, к номеру звонящего автоматически будет добавлен необходимый префикс “9”, таким образом, все участники из ринг-группы, смогут очень просто сразу вызвать абонента заново.
Если Вы хотите побольше узнать о группах вызова, прочитайте нашу соответствующую статью о настройке модуля Ring Groups во FreePBX 13.
Синтаксис
Обобщим все вышесказанное и сведем в таблицу принципы формирования переменных:
Пример
Описание
${переменная:n}
убирает одну цифру спереди. Например, если звонок приходит вам с Caller ID Number +74951234567, то запись вида ${CALLERID(num):1} преобразует его в 74951234567
${переменная:-n}
тоже самое, только цифры буду удаляться с конца. Например, при записи ${CALLERID(num):-2} номер +74951234567 будет преобразован в +749512345
${переменная:s:n}
Данную запись следуют интерпретировать так: начиная с символа s удалить n символов. Например, запись вида ${CALLERID(num):3:2} преобразует номер +74951234567 в +741234567