По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В программно-конфигурируемой сети (SDN) происходит разделение плоскости передачи и управления данными, позволяющее осуществить программное управление плоскостью передачи, которое может быть физически или логически отделено от аппаратных коммутаторов и маршрутизаторов. Подобный подход дает большое количество плюсов:
Возможность видеть топологию всей сети;
Возможность конфигурации всей сети в целом, а не отдельных единиц оборудования;
Возможность производить независимое обновление оборудования в сети;
Возможность контролировать всей сети из высокоуровневого приложения.
SDN сети
То есть, основное отличие программно-конфигурируемых сетей - делегация задачи вычисления маршрутов контроллеру (плоскость управления) и оставить функцию передачи пакетов (плоскость передачи данных) на отдельных устройствах (коммутаторы OpenFlow) , что снизит нагрузку на маршрутизатор и увеличит его производительность.
Для оценки функциональности SDN-сети с элементами NFV можно использовать два основных подхода, со своими достоинствами и недостатками:
Метод
Достоинства
Недостатки
Эмуляция
Высокая точность, возможность использования настоящего ПО
Возможная несовместимость конфигурации с реальным оборудованием
Построение сети на реальном оборудовании
Высокая точность результатов
Высокая стоимость
С началом развития в сфере SDN-сетей появилось два эмулятора SDN-сетей, которые в добавок поддерживают симуляцию (возможность тестирования сети, часть оборудования в которой реальна и часть - эмулирована).
Рассмотрим эмуляторы подробнее.
Mininet
Эмулятор, находящийся в свободном доступе, большая часть которого написана на языке Python. Работает с “легковесной” виртуализацией, то есть вся эмулируемая сеть реальна, в том числе и конечные виртуальные машины. Есть возможность подключения любых виртуальных коммутаторов и контроллеров.
Достоинства
Недостатки
Открытый код, бесплатность, быстродействие, поддержка всех контроллеров SDN и протоколов OpenFlow вплоть до 1.3, большое количество обучающих видео
Высокая сложность, необходимо знание Python и Linux, отсутствие полноценного графического интерфейса
Estinet
Эмулятор, все права на который имеет компания Estinet, но для студентов и всех желающих попробовать есть свободный доступ на месяц. Есть удобный графический интерфейс для построения топологии сети, редакции свойств оборудования и запуска эмуляции.
Достоинства
Недостатки
Наглядность, простота настройки и установки, возможность эмуляции LTE и Wi-Fi сетей
Закрытость, малое количество обучающих статей и видео, низкая производительность работы, более высокая сложность настройки при использовании не встроенного контроллера
Ниже приведена часть программного кода на языке Python для построения сети в эмуляторе Mininet:
# Инициализация топологии
Topo.__init__( self, **opts )
# Добавление узлов, первые - коммутаторы
S1 = self.addSwitch( 's0' )
S2 = self.addSwitch( 's1' )
S3 = self.addSwitch( 's2' )
S4 = self.addSwitch( 's3' )
S5 = self.addSwitch( 's4' )
S6 = self.addSwitch( 's5' )
S7 = self.addSwitch( 's6' )
S8 = self.addSwitch( 's7' )
S9 = self.addSwitch( 's8' )
S10= self.addSwitch( 's9' )
S11= self.addSwitch( 's10')
# Далее - рабочие станции(виртуальные машины)
H1= self.addHost( 'h0' )
H2 = self.addHost( 'h1' )
H3 = self.addHost( 'h2' )
H4 = self.addHost( 'h3' )
H6 = self.addHost( 'h5' )
H7 = self.addHost( 'h6' )
H8 = self.addHost( 'h7' )
H9 = self.addHost( 'h8' )
H10 = self.addHost( 'h9' )
H11 = self.addHost( 'h10' )
# Добавление каналов связи между коммутатором и рабочей станцией
self.addLink( S1 , H1 )
self.addLink( S2 , H2 )
self.addLink( S3 , H3 )
self.addLink( S4 , H4 )
self.addLink( S7 , H7 )
self.addLink( S8 , H8)
self.addLink( S9 , H9)
self.addLink( S10 , H10)
self.addLink( S11 , H11)
# Добавление каналов связи между коммутаторами
self.addLink( S1 , S2, bw=1, delay='0.806374975652ms')
self.addLink( S1 , S3, bw=1, delay='0.605826192092ms')
self.addLink( S2 , S11, bw=1000, delay='1.362717203ms')
self.addLink( S3 , S10, bw=1000, delay='0.557936322ms')
self.addLink( S4 , S5, bw=1000, delay='1.288738ms')
self.addLink( S4 , S7, bw=1000, delay='1.1116865ms')
self.addLink( S5 , S6, bw=1000, delay='0.590828707ms')
self.addLink( S5 , S7, bw=1000, delay='0.9982281ms')
self.addLink( S6 , S10, bw=1000, delay='1.203263ms')
self.addLink( S7 , S8, bw=1000, delay='0.2233403ms')
self.addLink( S8 , S9, bw=1000, delay='1.71322726ms')
self.addLink( S8 , S11, bw=1000, delay='0.2409477ms')
self.addLink( S9 , S10, bw=1000, delay='1.343440256ms')
self.addLink( S10 , S11, bw=1000, delay='0.544934977ms')
Сравнение контроллеров для построения сети
В данный момент, существует большое количество платных и бесплатных(открытых) контроллеров. Все нижеперечисленные можно скачать и установить на домашнюю систему или виртуальную машину. Рассмотрим самые популярные открытые контроллеры и их плюсы и минусы:
NOX - один из первых контроллеров, написан на языке C++;
POX - контроллер, похожий на NOX и написанный на языке Python;
OpenDayLight- контроллер, поддерживаемый многими корпорациями, написан на языке Java и постоянно развивающийся;
RunOS- российская разработка от Центра Прикладного Исследования Компьютерных Сетей (ЦПИКС), имеет графический интерфейс, подробную документацию и заявлена самая высокая производительность.
В таблице ниже рассмотрим плюсы и минусы каждого из контроллеров:
Название контроллера
Достоинства
Недостатки
NOX
Скорость работы
Низкое количество документации, необходимость знания C++
POX
Проще обучиться, много документации
Низкая скорость работы, необходимость знания Python, сложная реализация совместимости с NFV
OpenDayLight
Наличие графического интерфейса, поддержка VTN-сетей(NFV), наличие коммерческих продуктов на базе данного контроллера(Cisco XNC)
Сложность в использовании, сложная установка
RunOS
Высокая производительность, Российская разработка, Открытый код, Наличие графического интерфейса
Ранняя версия, возможные проблемы в эксплуатации по причине сырости продукта.
Система записи телефонных разговоров, позволяет компаниям иметь возможность оценивать качество работы сотрудников, отслеживать различные показатели взаимодействия с клиентом, разрешать спорные ситуации. Запись телефонных разговоров - это мощный инструмент, который позволяет оптимизировать работу компании, улучшить качество обслуживания и компетенции сотрудников.
На сегодняшний день, лидерами рынка систем записи являются ZOOM, Verint, Nice, Cisco (MediaSense).
По какому принципу работает система записи? На этот вопрос мы постараемся ответить.
Запись телефонных разговоров как правило делят на два типа: активная и пассивная. Активная (SPANLess) запись – это возможность телефонного аппарата напрямую отправлять RTP поток на сервер записи, а сигнальный трафик приходит через JTAPI*.
*JTAPI (Java Telephony Application Programming Interface) – специальный телефонный «эй-пи-ай», позволяющий интегрировать телефонные события.
Данный вариант зачастую реализуется при действующем кластере CUCM версией выше 6.0(Cisco Unified Communications Manager) и телефонах с поддержкой Built-in-Bridge.
Давайте посмотрим на схему работы активной записи:
Активный режим записи разговоров
В данном примере, пользователь А, звонит пользователю В. На телефоне пользователя А включен режим Built-in Bridge, и настроен соответствующий профиль записи. CUCM в этот момент фиксирует, что телефон пользователя В подлежит записи и начинает дублировать сигнализацию на интерфейс сервера записи. Вместе с тем, на сервер приходит и RTP поток от пользователя В. Медиа поток декодируется и соотносится с сигнализацией. По окончании обработки, через GUI системы записи мы видим наш разговор, с временными метками, DNIS, ANI и некоторые другие. В контактных центрах, так же возможна интеграция с платформой UCCX, UCCE, Genesys ,Avaya Communication Manager. В результате интеграции с данной платформой, будет возможно передавать агентскую информацию, CallType и многие другие параметры.
Давайте теперь разберемся с пассивной записью. Пассивная запись организуется путем настройки SPAN** – сессий для RTP траффика и сигнализации.
**SPAN (Switched Port Analyzer) – мониторинговая сессия, которая позволяет дублировать сетевой трафик с одного интерфейса на другой.
Чтобы на сервер записи не приходил ненужный трафик, как правило, настраивают RSPAN в сочетании листами доступа (access-list).
Давайте снова посмотрим на схему:
Пассивный (устаревший) режим записи разговоров
На схеме сверху, можно заметить, что роль CUCM сводится к управлению сигнализацией (SCCP или SIP). Предположим, что на центральном коммутаторе есть следующие настройки:
SPAN_SW(config)#monitor session 1 source interface f0/1
SPAN_SW(config)#monitor session 1 destination interface f0/3
Все, теперь траффик в обе стороны, как на прием, так и на передаче, с порта Fa 0/1 будет дублироваться на порт Fa 0/3. Можно вводить ограничения по SPAN-сессиям, например:
SPAN_SW(config)#monitor session 1 source interface f0/1 tx
SPAN_SW(config)#monitor session 1 destination interface f0/3
Это ограничение будет дублировать только исходящий (с порта) траффик. Таким образом, мы рассмотрели архитектурные особенности систем записи. Наша компания имеет большой опыт в инсталляции и поддержке систем записи.
Представьте себе, что рядом с вами в организации есть сетевая розетка и все, что туда подключается, автоматически получает туда доступ. Любые устройства - даже если они являются "шпионскими" или не авторизованными.
Вы конечно скажете - но есть же простой, как тапок, протокол под названием Port Security!
Верно, но как он работает? Вы либо указываете MAC-адрес, который может подключиться к порту и получить доступ в сеть, либо указываете какое-то количество таких MAC адресов, которые будут динамически опознаны коммутатором или смешиваете два этих способа.
Но что если вы находитесь в публичной зоне, например там, куда вы приглашаете клиентов, или, к примеру вы находитесь на некой веранде, откуда зачастую можно работать. Там внедрён Port Security, все нормально.
Но вдруг ваш ноутбук кто-то умудрился ловко спереть и что тогда? У кого-то постороннего появится доступ в вашу сеть, так как доступ по его MAC-адресу разрешен. Тут-то и вступает в дело 802.1X - он позволяет проводить аутентификацию не устройства, но пользователя. Таким образом, если устройство будет украдено, злоумышленники все равно не получат доступ в сеть.
Логичным вопросом будет "Как же я обеспечу гостей доступом в сеть без предоставления им полного доступа"? Ответ - легко, и вариантов десятки: гостевая учетка и гостевой VLAN, специальный портал саморегистрации для гостей и так далее и тому подобное.
Также некоторые скажут - ну конечно, у меня в компании доступ к беспроводной сети так и организован, через синхронизацию с AD и по учетным записям пользователей. Но как это работает в случае проводного доступа? Сразу отвечу, что 802.1X используется как в беспроводной сети, так и в проводной. Подробнее о принципе действия, его компонентах я расскажу ниже.
Из чего состоит 802.1X
У 802.1X есть три основных компонента - суппликант, аутентификатор и сервер аутентификации. Суппликант - это ваше оконечное устройство и пользователь с определенным ПО (здесь нет смысла углубляться в различные виды суппликантов).
Аутентификатор - это коммутатор или точка доступа (первое сетевое устройство уровня доступа, на который пришел трафик с суппликанта.
И, наконец, сервером аутентификации является специальное ПО или устройство, принадлежащее к классу NAC - Network Access Control, или средствам контроля сетевого доступа. Конкретный класс решений для реализации 802.1X называется RADIUS-сервером.
Итак, порядок подключения следующий: вы пытаетесь получить доступ в сеть и аутентификатор говорит - предъявите, пожалуйста документы. Ваше устройство (суппликант) предоставляет нужную информацию - логин и пароль, сертификат, обе этих сущности вместе и прочие. Далее аутентификатор отправляет полученную информацию на сервер аутентификации и ждёт ответа. Далее, в базовом варианте, сервер аутентификации отправит обратно на аутентификатор разрешение и после этого аутентификатор разрешение суппликанту. До этого момента почти никакой трафик разрешен не будет!
Важно понимать, что в сторону аутентификатора уходит фрейм с определенным регистром (для этого и нужен суппликант), а аутентификатор энкапсулирует отправляет полученную информацию от суппликанта в сторону сервера аутентификации как IP – пакет (чтобы его можно было маршрутизировать).
Протоколы в технологии 802.1X
Давайте теперь подробнее поговорим о протоколах в этой технологии – так как 802.1X являет собой неикий собирательный термин. Основных протоколов 2 – EAPoL (Extensible Authentication Protocol over LAN) и RADIUS (Remote Authentication Dial-In User Service).
Есть очень простые и не очень безопасные формы EAP и очень надежные, но крайне сложные в настройке. В простейшем виде будет необходим только логин и пароль. В более сложных – сертификат, токен и прочее. Есть правило – чем проще настроить EAP – тем он менее взломостойкий и наоборот :)
В наше время одним из популярных и очень умных RADIUS – серверов является Cisco ISE. Он позволяет авторизовывать пользователей в зависимости от их контекста: Что за устройство? Кто? Где? Когда? Было ли устройство скомпрометировано ранее? и автоматически профилировать каждое подключенное устройство для того, чтобы понимать какие устройства есть у вас в сети и в каком состоянии они находятся – многие даже не подозревают о том, как много у них в организации подключено неизвестных устройств (при количестве пользователей более 1000).
Ниже на диаграмме можно увидеть весь процесс установления соединения при использовании 802.1X: