По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В последние годы рынок программного обеспечения прогрессирует ударными темпами. Чтобы удержаться на плаву, компании-разработчики программного обеспечения постоянно разрабатывают новые решения и совершенствуют уже существующее программное обеспечение. И если в первом случае анализируются желания, озвучиваемые пользователями, то во втором более эффективным методом сбора данных оказывается телеметрия. Что же это такое? Говоря по-простому, сетевая телеметрия — это процесс автоматизированного сбора данных, их накопление и передача для дальнейшего анализа. Если говорить о программном обеспечении, то анализ проводится разработчиками софта с целью оптимизации существующих программ, либо разработки и внедрения новых решений. Телеметрия в сети осуществляется посредством сбора данных с использованием сетевого протокола NetFlow или его аналогов. Зачем же нужен NetFlow? Сетевой протокол NetFlow был разработан в конце прошлого века компанией Cisco. Изначально он использовался как программа-распределитель пакетов данных для оптимизации работы маршрутизаторов, однако с течением времени она была заменена на более эффективную программу. Тем не менее, такой функционал, как сбор полезной статистики по использованию сетевого трафика и поныне оставляет Netflow актуальным. Правда, специализация этого протокола уже не соответствует исходной. Тем не менее, Netflow обладает функционалом, который невозможно реализовать, применяя альтернативные сетевые технологии. Система постоянного наблюдения за работой сетевых приложений и действиями пользователей; Сбор и учет информации об использовании сетевого трафика; Анализ и планирование развития сети; Распределение и управление сетевым трафиком; Изучение вопросов сетевой безопасности; Хранение собранных посредством телеметрии данных и их итоговый анализ; Хотя уже существуют программные решения, обладающие схожим функционалом, решение от компании Cisco до сих пор остается одним из лучших в этой сфере. Кстати, теперь это решение называется Cisco Stealthwatch и на 95% обладает функционалом для решения исключительно задач, связанных с информационной безопасностью. Отметим, что технологию сбора данных посредством NetFlow поддерживают не все роутеры или коммутаторы. Если Ваше устройство имеет поддержку данного протокола, то оно будет замерять проходящий трафик и передавать собранные данные в NetFlow-коллектор для последующей обработки. Передача будет осуществляться в формате датаграмм протокола UDP или пакетов протокола SCTP, поэтому на скорость работы интернета существенным образом это не повлияет. В настоящее время решения NetFlow (как и многих других приложений) подразделяются на три типа: Базовые технологии. Отличаются низкой ценой и довольно скудным функционалом анализа сетевого трафика. Тем не менее, для большинства пользователей или же для изучения технологии этого вполне достаточно «Продвинутые» корпоративные варианты. Здесь базовый функционал дополнен более широким набором инструментов для предоставления расширенной отчетности анализа данных. Также эти решения содержат готовые модели оптимизации для разных сетевых устройств. «Флагманские» корпоративные решения. Отличаются наивысшей ценой, однако при этом и наиболее широким функционалом, а также позволяют осуществлять мониторинг информационной безопасности в крупных организациях. «А как же быть с приватностью? Ведь сбор данных ставит под угрозу частную жизнь пользователей, тайну переписки, личные сообщения и прочее» - спросит беспокойный читатель. Согласно политике приватности компании Cisco, персональные данные пользователей остаются в полной безопасности. Посредством телеметрии NetFlow анализируется исключительно передача сетевого трафика, не угрожая приватности пользователей. Примеры решений Также приведем несколько самых популярных сетевых анализаторов, работающих под протоколом NetFlow: Solarwinds NetFlow Traffic Analyzer – мощный инструмент для анализа динамики трафика в сети. Программа осуществляет сбор, накопление и анализ данных, выводя их в удобном для пользователя формате. При этом можно проанализировать поведение трафика за определенные временные промежутки. Для ознакомления на сайте производителя доступна бесплатная 30-дневная версия Flowmon – программа, предоставляющая комплекс инструментов для изучения пропускной способности сети, нагрузки на сеть в определенные периоды времени, а также обеспечения безопасности сети от DDOS-атак PRTG Network Monitor - универсальное решение для сбора, хранения и обработки данных о поведении сети. В отличие от других подобных программ, данный инструмент работает на основе сенсоров – логических единиц, отвечающих за сбор данных по определенным аспектам изучаемого устройства. ManageEngine NetFlow Analyzer – схожая с остальными по функционалу программа. Её выделяют из ряда других такие возможности, как гибкая настройка аналитики, а так же возможность мониторить поведение сети из любого места, благодаря приложению для телефона. Как можно заметить, все вышеуказанные программы не только обладают схожим базовым функционалом, но и конкурируют между собой, продумывая и внедряя новые технические решения. Выбор, какой из нескольких десятков программ начать пользоваться – целиком и полностью дело конечного пользователя.
img
Пока не создан единый протокол маршрутизации, управляющий остальными, существует необходимость в том, чтобы несколько протоколов маршрутизации мирно сосуществовали в одной сети. К примеру, одна компания работает с OSPF, а другая компания работает с EIGRP, и эти две компании слились в одно целое предприятие. Пока вновь образованный ИТ-персонал не перейдет для использования на единый протокол маршрутизации (возможно они когда-нибудь это сделают), маршруты, известные протоколу OSPF, необходимо объявить в часть сети, работающей под управлением EIGRP, и наоборот. Упомянутый выше сценарий возможен благодаря Route redistribution, и именно этому посвящена данная статья. Другие причины, по которым вам потребуется выполнить Route redistribution, это: различные части сети конкретной компании находятся под различным административным контролем; если необходимо объявить маршруты своему поставщику услуг через BGP, или, возможно, необходимо подключиться к сети делового партнера. Рассмотрим следующую базовую топологию. В простой топологии, показанной выше, мы хотим, чтобы OSPF и EIGRP объявляли друг другу маршруты, о которых они знают. Эта концепция называется взаимным перераспределением маршрутов. Поскольку роутер CENTR имеет один интерфейс в автономной системе OSPF (AS) и один интерфейс в EIGRP AS, он несет ответственность за выполнение Route redistribution. Seed Metrics Основная проблема, с которой мы сталкиваемся при Route redistribution между различными протоколами маршрутизации, заключается в разнообразных подходах, применяемых протоколами маршрутизации для измерения своих метрик. Например, OSPF использует cost-метрику, которая основана на bandwidth, в то время как EIGRP использует метрику, основанную на bandwidth и delay, но также может учитывать надежность или (и) нагрузку (и даже использовать Maximum Transmission Unit (MTU) в качестве прерывания связи). Итак, что же нам делать? Мы, как администраторы, можем настроить метрику, назначенную маршрутам, поступающим из одной AS, которые перераспределяются в другую AS. Если нам лень вручную настраивать метрику, которая будет использоваться для Route redistribution, то используется seed metric. В следующей таблице показаны seed metrics, используемые различными протоколами маршрутизации. Основываясь на приведенной выше таблице, мы видим, что, маршрутам, которые перераспределяются в OSPF по дефолту будет назначена метрика 20, если же маршруты, перераспределяются в протокол OSPF от протокола BGP, то им будет присвоено значение метрики 1. Интересно, что и RIP, и EIGRP по умолчанию имеют seed metrics бесконечности. Это означает, что любой маршрут, перераспределенный в эти протоколы маршрутизации, будет считаться недостижимым по умолчанию и поэтому не объявляются никаким другим роутерам. BGP, однако, перераспределяет маршрут, полученный из протокола внутреннего шлюза (IGP), используя исходную метрику этого маршрута. Пример базовой настройки Конечно, есть еще много вопросов, связанных с перераспределением маршрутов, таких как циклы маршрутизации, которые могут возникнуть, когда у нас есть несколько роутеров, соединяющих наши автономные системы, или выборочная фильтрация определенных маршрутов от перераспределения. Но мы вернемся ко всему этому в следующих статьях. А пока давайте разберемся, как выполнить базовую настройку Route redistribution (перераспределения маршрутов). Рассмотрим предыдущую топологию, на этот раз с добавлением информации о сети и интерфейсе: В этой топологии роутер CENTR изучает маршруты от OFF1 через OSPF и от OFF2 через EIGRP. Это видно в выходных данных команды show ip route, отображенной на CENTR: Однако ни роутер OFF1, ни роутер OFF2 не изучили никаких маршрутов, потому что роутер CENTR еще не выполняет Route redistribution. Об этом свидетельствует вывод команды show ip route, отображенной на OFF1 и OFF2: Теперь давайте добавим конфигурацию Route redistribution к роутеру CENTR. Чтобы подтвердить предыдущее утверждение о том, что seed metric для маршрутов, перераспределяемых в EIGRP, является бесконечностью, мы изначально не будем настраивать какие-либо метрики и позволим seed metric вступить в силу. CENTR# conf term Enter configuration commands, one per line. End with CNTL/ Z CENTR(config)#router ospf 1 CENTR(config-router)#redistribute eigrp 1 CENTR(config-router)#exit CENTR(config)#router eigrp 1 CENTR(config-router)# redistribute ospf 1 CENTR(config-router)#end CENTR# Команда redistribute применена в режиме конфигурации роутера для каждого протокола маршрутизации, и метрика не была указана. Важно, что, когда мы ввели команду redistribute eigrp 1 выше, мы не включили ключевое слово subnets в команду, которая заставляет как классовые, так и бесклассовые сети перераспределяться в OSPF. Однако, как видно из приведенных ниже выходных данных, ключевое слово subnets было автоматически добавлено для нас: Данное поведение автоматического добавления ключевого слова subnets наблюдается в последних версиях Cisco IOS. Некоторые, более старые версии Cisco IOS, не включают автоматически ключевое слово subnets, и вам может потребоваться вручную добавить его в команду redistribute. Давайте теперь взглянем на таблицы IP-маршрутизации на роутерах OFF1 и OFF2, чтобы увидеть, какие маршруты они изучили (и не изучили). Приведенные выше выходные данные показывают нам, что роутер CENTR успешно перераспределил маршруты, известные EIGRP в OSPF, которые затем были изучены роутером OFF1. Обратите внимание, что перераспределенные маршруты, известные роутеру OFF1, имеют метрику 20, которая является seed metrics OSPF. Однако роутер OFF2 не изучал никаких новых маршрутов, потому что, когда роутер CENTR перераспределял маршруты в EIGRP, он использовал seed metrics EIGRP бесконечность (что означает недостижимость). В результате эти маршруты не были объявлены роутеру OFF2. Чтобы решить эту проблему, нам нужно назначить метрику маршрутам, перераспределяемым в EIGRP. Существует три основных способа присвоения не дефолтных метрик маршрутам, перераспределяемым в протокол маршрутизации.. Установите метрику по умолчанию для всех протоколов маршрутизации, перераспределяемых в определенный протокол маршрутизации. Установите метрику как часть команды redistribute. Установите метрику используя route-map Чтобы проиллюстрировать первый вариант, давайте настроим метрику для назначения всем маршрутам, перераспределяемым в EIGRP. CENTR#configuration terminal Enter configuration commands, one per line. End with CNTL/Z. CENTR (config)#router eigrp 1 CENTR (config-router)#default-metric ? 1-4294967295 Bandwidth in Kbits per second CENTR (config-router)#default-metric 1000000 ? 0-4294967295 delay metric in 10 microsecond units CENTR(config-router)#default-metric 1000000 1 ? 0-255 Reliability metric where 255 is 100% reliable CENTR (config-router)#default-metric 1000000 1 255 ? 1-255 Effective bandwidth metric (Loading) where 255 is 100% loaded CENTR (config-router)#default-metric 1000000 1 255 1 ? 1-65535 Maximum Transmission Unit metric of thenpath CENTR (config-router)#default-metric 1000000 1 255 1 1500 CENTR (config-router)#end CENTR# Контекстно-зависимая справка была использована в приведенном выше примере для отображения каждого компонента метрики, назначаемого маршрутам, перераспределяемым в EIGRP. Однако последняя команда была default-metric 1000000 1 255 1 1500. Если бы мы устанавливали default-metric для OSPF, мы могли бы использовать такую команду, как default-metric 30, чтобы назначить стоимость 30 OSPF маршрутам, перераспределяемым в OSPF. Однако в этом примере мы указали только default-metric для EIGRP. Давайте теперь проверим таблицу IP-маршрутизации на роутере OFF2, чтобы увидеть, были ли маршруты OSPF успешно объявлены в EIGRP. Прекрасно! Роутер OFF2 изучил маршруты, происходящие из OSPF AS. Мы знаем, что маршруты первоначально пришли из-за пределов EIGRP, из-за кода EX, появляющегося в каждом из этих маршрутов. Второй вариант установки метрики на Route Redistribution состоял в том, чтобы назначить метрику как часть команды redistribute, которая позволяет нам указать различные метрики для различных протоколов маршрутизации, перераспределяемых в процесс маршрутизации. Чтобы проиллюстрировать этот подход, давайте удалим предыдущие команды default-metric и redistribute из роутера CENTR и введем команду redistribute, которая определяет метрику, которая будет назначена. CENTR#configuration terminal Enter configuration commands, one per line. End with CNTL/Z. CENTR(config)#router eigrp 1 CENTR(config-router)#no default-metric 1000000 1 255 1 1500 CENTR(config-router)#no redistribute ospf 1 CENTR(config-router)#redistribute ospf 1 ? Match Redistribution of OSPF routes metric Metric for redistributed routes route-map Route map reference cr CENTR(config-router)#redistribute ospf 1 metric 1000000 1 255 1 1500 CENTR(config-router)#end CENTR# Если мы сейчас вернемся к роутеру OFF2, то получим тот же результат, что и раньше: Третьим вариантом установки метрики для Route Redistribution использовании маршрутной карты (route-map). Маршрутные карты являются супермощными и могут быть использованы для различных конфигураций. По сути, они могут соответствовать определенному трафику и устанавливать один или несколько параметров (например, IP-адрес следующего прыжка) для этого трафика. Однако в нашем контексте мы просто будем использовать route-map для указания значения метрики, а затем применим ее к команде redistribute. В следующем примере показано, как мы можем удалить нашу предыдущую команду redistribute из роутера CENTR, создать route-map, а затем ввести новую команду redistribute, которая ссылается на нашу карту маршрута (route-map): CENTR#configuration terminal Enter configuration commands, one per line. End with CNTL/Z. CENTR(config)#router eigrp 1 CENTR(config-router)#no redistribute ospf 1 metric 1000000 1 255 1 1500 CENTR(config-router)#exit CENTR(config)#route-map SET-МETRIC-DEMO CENTR(config-route-map)#set metric 1000000 1 255 1 1500 CENTR(config-route-map)#exit CENTR(config)#router eigrp 1 CENTR(config-router)#redistribute ospf 1 route-map SET-МETRIC-DEMO CENTR(config-router)#end CENTR# В приведенном выше примере, после удаления нашей команды redistribute, мы создали карту маршрута с именем SET-METRIC-DEMO. Это был очень простой route-map, которая не должна была соответствовать никакому траффику. Он был просто использован для установки метрики. Однако в следующей статье мы увидим, что route-map может быть использована, чтобы дать нам больше контроля над нашим перераспределением маршрутов. В нашем текущем примере карта маршрута была затем применена к нашей новой команде redistribute. Опять же, это дает нам тот же результат с точки зрения таблицы IP-маршрутизации роутера OFF2: OSPF E1 или E2 Routes Прежде чем мы закончим эту статью в нашей серии Route redistribution, давайте еще раз рассмотрим таблицу IP-маршрутизации на роутере OFF1: Обратите внимание, что каждый из маршрутов, перераспределенных в OSPF, отображается в таблице IP-маршрутизации роутера OFF1 с кодом E2. Однако наблюдаются также код E1, оба указывающих, что маршрут возник из-за пределов OSPF AS роутера. Итак, в чем же разница между этими двумя кодами? Код E2 указывает, что маршрут несет метрику, назначенную роутером, выполняющим перераспределение, который известен как автономный системный пограничный роутер (ASBR). Это означает, что независимо от того, сколько дополнительных роутеров в OSPF мы должны пересечь, чтобы вернуться к ASBR, метрика остается такой же, какой она была, когда ASBR перераспределил ее. Когда мы перераспределяем маршруты в OSPF, эти маршруты, по дефолту, являются этими External Type 2 (E2). Код E1 указывает, что метрика маршрута состоит из первоначальной стоимости, назначенной ASBR, плюс стоимость, необходимая для достижения ASBR. Это говорит о том, что маршрут Е1, как правило, более точен, и на самом деле это так. Хотя наличие кода E1 не дает нам никакого преимущества в простой топологии, как у нас, где роутер OFF1 имеет только один путь для достижения ASBR (т. е. CENTR), и где есть только один способ для маршрутов EIGRP быть введенными в наш OSPF AS (т. е. через роутер CENTR). Если мы хотим перераспределить маршруты E1 в OSPF вместо маршрутов E2, то это можно сделать с помощью команды redistribute. В следующем примере мы удаляем нашу команду redistribute для процесса маршрутизации OSPF на роутере CENTR, а затем повторно применяем команду redistribute, указывающую, что мы хотим, чтобы External Type 1 (E1) применялись к перераспределенным маршрутам. CENTR#configuration terminal Enter configuration commands, one per line. End with CNTL/Z. CENTR(config)#router ospf 1 CENTR(config-router)#no redistribute eigrp 1 subnets CENTR(config-router)#redistribute eigrp 1 metric-type ? 1 Set OSPF External Туре 1 metrics 2 Set OSPF External Туре 2 metrics CENTR(config-router)#redistribute eigrp 1 metric-type 1 CENTR(config-router)#end CENTR#show Давайте проверим таблицу IP-маршрутизации на роутере OFF1, чтобы увидеть, изменились ли параметры на основе этой новой команды redistribute, введенной на роутере CENTR. В приведенных выше выходных данных обратите внимание, что маршруты, перераспределенные в OSPF, имеют код E1, а не дефолтный код E2. Кроме того, обратите внимание, что это приводит к тому, что метрика этих маршрутов будет немного выше. В частности, роутер CENTR перераспределил EIGRP-изученные маршруты в OSPF, используя начальную метрику OSPF 20. Однако существует стоимость OSPF 1, чтобы добраться от роутера OFF1 до роутера CENTR. Таким образом, поскольку перераспределенные маршруты были сконфигурированы как маршруты E1, стоимость этих маршрутов с точки зрения роутера OFF1 является стоимостью, первоначально назначенной роутером OFF1, которая составляла 20, плюс стоимость для OFF1, чтобы добраться до CENTR, который равен 1, итого общей стоимости 21. Отлично, теперь вы знаете, как делать перераспределение маршрутов. Теперь почитайте, как сделать Фильтрацию маршрутов с помощью карт маршрутов.
img
В данной статье рассмотрим процесс настройки интеграции 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. Команда из Битрикса на будет передавать на этот порт и обрабатываться модулем. Сохраняем. Попадаем на страницу с результатами всех проверок Другая часть бизнес-логики В результате должно получиться вот так: при входящем или исходящем звонке показывается карточка звонка: После завершения звонка в лиде создается звонок. При пропущенном входящем звонке создается задача.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59