По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В наше время, время цифровых технологий и интернета, уже невозможно представить современный бизнес без компьютеризированных технологий и новейших гаджетов.
Точно так же невозможно представить управление этим бизнесом без современной и удобной видеоконференцсвязи (ВКС), которая позволяет сэкономить время и деньги.
В наше время уже не обязательно лететь на другой конец света, чтобы заключить сделку/соглашение или дать указание подчиненному. Достаточно просто связаться по ВКС и проблема решена, никаких авиаперелетов и долгих поездок, ВКС - это выбор современной, двигающейся в ногу со временем, экономически продвинутой компании!
Популярность видеоконференцсвязи, среди компаний и бизнес-корпораций, повлияла на создание множества продуктов разных разработчиков, но все они имеют один серьезный недостаток - они несовместимы. Большая часть ВКС-решений, которые были представлены на рынке, построены на базе личных протоколов и стандартов, поэтому соединение систем различных производителей в одну единую систему - очень проблематичная и дорогостоящая задача, решением которой стало появление системы Meeting Server.
И сегодня мы с Вами поговорим о такой системе конференцсвязи, как Cisco Meeting Server.
Cisco Meeting Server является универсальной программой для подключения к ВКС.
Иными словами, данная система, позволяет подключиться к ВКС, независимо от вида, модели, и устройства видеоконференцсвязи:
смартфон;
ноутбук;
специальная комната для ВКС и другие.
Cisco Meeting Server - перевел видеоконференцсвязь на новый уровень
Так же, Cisco Meeting Server, позволяет подключиться к видеоконференции независимо от типа программного обеспечения при помощи:
видеоканалов Cisco или других компаний;
Cisco Jabber;
Skype for Business;
Cisco Meeting App (с помощью совместимого с WebRTC браузера).
Cisco Meeting Server - особенная модель лицензирования, не зависящая ни от кого сервера конференций и устроенная не на лицензировании количества видео соединений, а на лицензировании ВКС в целом
Основной из уникальных функций платформы Cisco Meeting Server является возможность объединения стандартных систем видеоконференцсвязи со Skype for Business.
Клиенты Skype for Business могут реализовывать видео-звонки на стандартные видеосистемы, с поддержкой высочайшего качества видео, и двухстороннего обмена различными аудио и видео материалами.
Стоит заметить, что, любая система ВКС в вашей компании или даже виртуальная комната пользователя на Cisco Meeting Server может быть добавлена в список контактов программного клиента Skype for Business, и звонки на нее будет выглядеть аналогично звонкам абонентам Skype.
Возникает вопрос: "Что же такое на самом деле Cisco Meeting Server, и является ли данная программа новейшей современной разработкой, или это очередная покупка Cisco?".
Начнем по порядку, и постараемся разобраться, где правда, а где фейк.
Основой системы Cisco Meeting Server являются разработки компании Acano, которую Cisco купила в январе 2016 года.
Acano- британская компания, занимающаяся производством аппаратной инфраструктуры для проведения совместной работы и программного обеспечения для видеоконференцсвязи. Оборудование и программы, которые выпускает Acano, позволяют компаниям находить взаимодействие ВКС-систем различных производителей. По сути, чем и является в данный момент Cisco Meeting Server.
Покупка Cisco, стартапа компании Acano, рискованный, но единственно верный шаг
Cisco Meeting Server могут оснащать совершенно любые организации- которые имеют лишь нескольких пользователей и до крупнейших бизнес-корпораций с тысячами сотрудников. Необходимые системы безопасности уже установлены в решение.
Клиенты могут устанавливать Cisco Meeting Server на основе разрешений по количеству пользователей, приобретая необходимый объем услуг и увеличивать его по мере необходимости.
Компания мотивирует партнеров в соединении переводить имеющуюся инфраструктуру ВКС на Cisco Meeting Server, что показывает абсолютно новые возможности прибыли,
Способствуя ускорению этого перехода, Cisco предлагает партнерам возможность перемещения со скидкой, чтобы ускорить обновление, а так же облегченное лицензирование при интеграции персональных систем.
Теперь, если заказчик выбрал систему Microsoft, а не Cisco, партнеры все равно не упустят возможность.
Иными словами, участник имеет возможность создать комплекс структур, который позволит обеспечить функциональную совместимость там, где это необходимо, и это гарантия того, что любая возможность, попадающая на стол партнёру, будет такой, где можно будет осуществить продажу.
В этой первой части статьи мы сначала рассмотрим некоторые методы обслуживания сетей. Существуют различные модели, которые помогут вам поддерживать ваши сети и сделать вашу жизнь проще. Во второй части статьи мы рассмотрим некоторые теоретические модели, которые помогут вам в устранении неполадок.
Ну что давайте начнем рассматривать техническое обслуживании сети! Обслуживание сети в основном означает, что вы должны делать все необходимое для поддержания сети в рабочем состоянии, и это включает в себя ряд задач:
Устранение неполадок в сети;
Установка и настройка аппаратного и программного обеспечения;
Мониторинг и повышение производительности сети;
Планирование будущего расширения сети;
Создание сетевой документации и поддержание ее в актуальном состоянии;
Обеспечение соблюдения политики компании;
Обеспечение соблюдения правовых норм;
Обеспечение безопасности сети от всех видов угроз.
Конечно, этот список может отличаться для каждой сети, в которой вы работаете. Все эти задачи можно выполнить следующим образом:
Структурированные задачи;
Interrupt-driven задачи.
Структурированный означает, что у вас есть заранее определенный план обслуживания сети, который гарантирует, что проблемы будут решены до того, как они возникнут. Как системному администратору, это сделает жизнь намного проще. Управляемый прерыванием означает, что вы просто ждете возникновения проблемы, а затем исправляете ее так быстро, как только можете. Управляемый прерыванием подход больше похож на подход "пожарного" ...вы ждете, когда случится беда, а затем пытаетесь решить проблему так быстро, как только можете. Структурированный подход, при котором у вас есть стратегия и план обслуживания сети, сокращает время простоя и является более экономичным.
Конечно, вы никогда не сможете полностью избавиться от Interrupt-driven, потому что иногда все "просто идет не так", но с хорошим планом мы можем точно сократить количество задач, управляемых прерываниями.
Вам не нужно думать о модели обслуживания сети самостоятельно. Есть ряд хорошо известных моделей обслуживания сети, которые используются сетевыми администраторами. Лучше всего использовать одну из моделей, которая лучше всего подходит для вашей организации и подкорректировать, если это необходимо.
Вот некоторые из известных моделей обслуживания сети:
FCAPS:
Управление неисправностями.
Управление конфигурацией.
Управление аккаунтингом.
Управление производительностью.
Управление безопасностью.
Модель обслуживания сети FCAPS была создана ISO (Международной организацией стандартизации).
ITIL: библиотека ИТ-инфраструктуры - это набор практик для управления ИТ-услугами, который фокусируется на приведении ИТ-услуг в соответствие с потребностями бизнеса.
TMN: сеть управления телекоммуникациями - это еще одна модель технического обслуживания, созданная ITU-T (сектор стандартизации телекоммуникаций) и являющаяся вариацией модели FCAPS. TMN нацелена на управление телекоммуникационными сетями.
Cisco Lifecycle Services: конечно, Cisco имеет свою собственную модель обслуживания сети, которая определяет различные фазы в жизни сети Cisco:
Подготовка
Планирование
Проектирование
Внедрение
Запуск
Оптимизация
Выбор модели обслуживания сети, которую вы будете использовать, зависит от вашей сети и бизнеса. Вы также можете использовать их в качестве шаблона для создания собственной модели обслуживания сети.
Чтобы дать вам представление о том, что такое модель обслуживания сети и как она выглядит, ниже приведен пример для FCAPS:
Управление неисправностями: мы будем настраивать наши сетевые устройства (маршрутизаторы, коммутаторы, брандмауэры, серверы и т. д.) для захвата сообщений журнала и отправки их на внешний сервер. Всякий раз, когда интерфейс выходит из строя или нагрузка процессора превышает 80%, мы хотим получить сообщение о том, чтобы узнать, что происходит.
Управление конфигурацией: любые изменения, внесенные в сеть, должны регистрироваться в журнале. Чаще всего используют управление изменениями, чтобы соответствующий персонал был уведомлен о планируемых изменениях в сети. Изменения в сетевых устройствах должны быть зарегистрированы и утверждены до того, как они будут реализованы.
Управление аккаунтингом: Мы будем взимать плату с (гостевых) пользователей за использование беспроводной сети, чтобы они платили за каждые 100 МБ данных или что-то в этом роде. Он также обычно используется для взимания платы с людей за междугородние VoIP-звонки.
Управление производительностью: производительность сети будет контролироваться на всех каналах LAN и WAN, чтобы мы знали, когда что-то пойдет не так. QoS (качество обслуживания) будет настроено на соответствующих интерфейсах.
Управление безопасностью: мы создадим политику безопасности и реализуем ее с помощью брандмауэров, VPN, систем предотвращения вторжений и используем AAA (Authorization, Authentication and Accounting) для проверки учетных данных пользователей. Сетевые нарушения должны регистрироваться, и должны быть приняты соответствующие мероприятия.
Как вы видите, что FCAPS - это не просто "теоретический" метод, но он действительно описывает "что", "как" и "когда" мы будем делать.
Какую бы модель обслуживания сети вы ни решили использовать, всегда есть ряд рутинных задач обслуживания, которые должны иметь перечисленные процедуры, вот несколько примеров:
Изменения конфигурации: бизнес никогда не стоит на месте, он постоянно меняется. Иногда вам нужно внести изменения в сеть, чтобы разрешить доступ для гостевых пользователей, обычные пользователи могут перемещаться из одного офиса в другой, и для облегчения этой процедуры вам придется вносить изменения в сеть.
Замена оборудования: старое оборудование должно быть заменено более современным оборудованием, и также возможна ситуация, когда производственное оборудование выйдет из строя, и нам придется немедленно заменить его.
Резервные копии: если мы хотим восстановиться после сетевых проблем, таких как отказавшие коммутаторы или маршрутизаторы, то нам нужно убедиться, что у нас есть последние резервные копии конфигураций. Обычно вы используете запланированные резервные копии, поэтому вы будете сохранять текущую конфигурацию каждый день, неделю, месяц или в другое удобное для вас время.
Обновления программного обеспечения: мы должны поддерживать ваши сетевые устройства и операционные системы в актуальном состоянии. Обновления позволяют исправлять ошибки ПО. Также обновление проводится для того, чтобы убедиться, что у нас нет устройств, на которых работает старое программное обеспечение, имеющее уязвимости в системе безопасности.
Мониторинг: нам необходимо собирать и понимать статистику трафика и использования полосы пропускания, чтобы мы могли определить (будущие) проблемы сети, но также и планировать будущее расширение сети.
Обычно вы создаете список задач, которые должны быть выполнены для вашей сети. Этим задачам можно присвоить определенный приоритет. Если определенный коммутатор уровня доступа выходит из строя, то вы, вероятно, захотите заменить его так быстро, как только сможете, но нерабочее устройство распределения или основного уровня будет иметь гораздо более высокий приоритет, поскольку оно влияет на большее число пользователей Сети.
Другие задачи, такие как резервное копирование и обновление программного обеспечения, могут быть запланированы. Вы, вероятно, захотите установить обновления программного обеспечения вне рабочего времени, а резервное копирование можно запланировать на каждый день после полуночи. Преимущество планирования определенных задач заключается в том, что сетевые инженеры с меньше всего забудут их выполнить.
Внесение изменений в вашу сеть иногда влияет на производительность пользователей, которые полагаются на доступность сети. Некоторые изменения будут очень важны, изменения в брандмауэрах или правилах списка доступа могут повлиять на большее количество пользователей, чем вы бы хотели. Например, вы можете установить новый брандмауэр и запланировать определенный результат защиты сети. Случайно вы забыли об определенном приложении, использующем случайные номера портов, и в конечном итоге устраняете эту проблему. Между тем некоторые пользователи не получат доступ к этому приложению (и возмущаются, пока вы пытаетесь его исправить...).
Более крупные компании могут иметь более одного ИТ-отдела, и каждый отдел отвечает за различные сетевые услуги. Если вы планируете заменить определенный маршрутизатор завтра в 2 часа ночи, то вы можете предупредить парней из отдела "ИТ-отдел-2", о том, что их серверы будут недоступны. Для этого можно использовать управление изменениями. Когда вы планируете внести определенные изменения в сеть, то другие отделы будут проинформированы, и они могут возразить, если возникнет конфликт с их планированием.
Перед внедрением управления изменениями необходимо подумать о следующем:
Кто будет отвечать за авторизацию изменений в сети?
Какие задачи будут выполняться во время планового технического обслуживания windows, linux, unix?
Какие процедуры необходимо соблюдать, прежде чем вносить изменения? (например: выполнение "copy run start" перед внесением изменений в коммутатор).
Как вы будете измерять успех или неудачу сетевых изменений? (например: если вы планируете изменить несколько IP-адресов, вы запланируете время, необходимое для этого изменения. Если для перенастройки IP-адресов требуется 5 минут, а вы в конечном итоге устраняете неполадки за 2 часа, так как еще не настроили. Из-за этого вы можете "откатиться" к предыдущей конфигурации. Сколько времени вы отводите на устранение неполадок? 5 минут? 10 минут? 1 час?
Как, когда и кто добавит сетевое изменение в сетевую документацию?
Каким образом вы создадите план отката, чтобы в случае непредвиденных проблем восстановить конфигурацию к предыдущей конфигурации?
Какие обстоятельства позволят отменить политику управления изменениями?
Еще одна задача, которую мы должны сделать - это создать и обновить вашу сетевую документацию. Всякий раз, когда разрабатывается и создается новая сеть, она должна быть задокументирована. Более сложная часть состоит в том, чтобы поддерживать ее в актуальном состоянии. Существует ряд элементов, которые вы должны найти в любой сетевой документации:
Физическая топологическая схема (физическая карта сети): здесь должны быть показаны все сетевые устройства и то, как они физически связаны друг с другом.
Логическая топологическая схема (логическая карта сети): здесь необходимо отобразить логические связи между устройствами, то есть как все связано друг с другом. Показать используемые протоколы, информация о VLAN и т. д.
Подключения: полезно иметь диаграмму, которая показывает, какие интерфейсы одного сетевого устройства подключены к интерфейсу другого сетевого устройства.
Инвентаризация: вы должны провести инвентаризацию всего сетевого оборудования, списков поставщиков, номера продуктов, версии программного обеспечения, информацию о лицензии на программное обеспечение, а также каждое сетевое устройство должно иметь инвентарный номер.
IP-адреса: у вас должна быть схема, которая охватывает все IP-адреса, используемые в сети, и на каких интерфейсах они настроены.
Управление конфигурацией: перед изменением конфигурации мы должны сохранить текущую запущенную конфигурацию, чтобы ее можно было легко восстановить в предыдущую (рабочую) версию. Еще лучше хранить архив старых конфигураций для дальнейшего использования.
Проектная документация: документы, которые были созданы во время первоначального проектирования сети, должны храниться, чтобы вы всегда могли проверить, почему были приняты те или иные проектные решения.
Это хорошая идея, чтобы работать с пошаговыми рекомендациями по устранению неполадок или использовать шаблоны для определенных конфигураций, которые все сетевые администраторы согласны использовать.
Ниже показаны примеры, чтобы вы понимали, о чем идет речь:
interface FastEthernet0/1
description AccessPoint
switchport access vlan 2
switchport mode access
spanning-tree portfast
Вот пример интерфейсов доступа, подключенных к беспроводным точкам доступа. Portfast должен быть включен для связующего дерева, точки доступа должны быть в VLAN 2, а порт коммутатора должен быть изменен на "доступ" вручную.
interface FastEthernet0/2
description VOIP
interface FastEthernet0/2
description ClientComputer
switchport access vlan 6
switchport mode access
switchport port-security
switchport port-security violation shutdown
switchport port-security maximum 1
spanning-tree portfast
spanning-tree bpduguard enable
Вот шаблон для интерфейсов, которые подключаются к клиентским компьютерам. Интерфейс должен быть настроен на режиме "доступа" вручную. Безопасность портов должна быть включена, поэтому допускается только 1 MAC-адрес (компьютер). Интерфейс должен немедленно перейти в режим переадресации, поэтому мы настраиваем spanning-tree portfast, и, если мы получаем BPDU, интерфейс должен перейти в err-disabled. Работа с предопределенными шаблонами, подобными этим, уменьшит количество ошибок, потому что все согласны с одной и той же конфигурацией. Если вы дадите каждому сетевому администратору инструкции по ""защите интерфейса", вы, вероятно, получите 10 различных конфигураций
interface GigabitEthernet0/1
description TRUNK
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk nonegotiate
Вот еще один пример для магистральных соединений. Если вы скажете 2 сетевым администраторам "настроить магистраль", вы можете в конечном итоге получить один интерфейс, настроенный для инкапсуляции 802.1Q, а другой-для инкапсуляции ISL. Если один сетевой администратор отключил DTP, а другой настроил интерфейс как "dynamic desirable", то он также не будет работать. Если вы дадите задание им настроить магистраль в соответствии с шаблоном, то у нас будет одинаковая конфигурация с обеих сторон.
Здравствуй дорогой друг! В этой статье мы хотим рассказать про базовую настройку отслеживания статического маршрута Static Route Tracking, используя IP SLA.
В современной сетевой среде избыточность является одним из наиболее важных аспектов, будь то на стороне локальной сети LAN или на стороне глобальной сети WAN. В этой статье мы рассмотрим избыточность WAN с несколькими каналами WAN, оканчивающимися на одном маршрутизаторе.
Лучший и самый простой способ достижения избыточности WAN на устройствах Cisco - это использовать надежные резервные статические маршруты с отслеживанием IP SLA.
IP SLA - это функция, включенная в программное обеспечение Cisco IOS, которая позволяет администраторам анализировать уровни обслуживания для IP приложений и сервисов, проверять QoS на соответствие параметрам, и помогать обнаруживать и локализовать неисправности. IP SLA использует технологию активного мониторинга трафика (когда тестовые пакеты добавляются в активное соединение) для мониторинга непрерывного трафика в сети. Маршрутизаторы Cisco предоставляют собой так называемые IP SLA Responder'ы, которые обеспечивают точность измеренных данных в сети. IP SLA собирает информацию об задержке, джиттере, потере пакетов, их пути, последовательности отправки и многого другого.
С IP SLA маршрутизаторы и коммутаторы выполняют периодические измерения. Количество и тип доступных измерений огромны, и в этой статье мы рассмотрим только функцию ICMP ECHO. Сам по себе IP SLA - очень большая тема для обсуждения.
Настройка
Рассмотрим следующую схему с двумя провайдерами.
На рисунке наше устройство Cisco подключено к двум каналам WAN - ISP1 и ISP2. Наиболее распространенная настройка, которую мы используем в повседневной жизни, - это настройка маршрутов по умолчанию на маршрутизаторе Cisco, указывающих на соответствующие IP-адреса следующего хопа (next-hop), как показано ниже:
R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10
Как вы могли заметить административное расстояние для дополнительного маршрута, указывающего на ISP2, увеличено до 10, чтобы он стал резервным каналом.
Вышеуказанная конфигурация с двумя плавающими статическими маршрутами частично выполняет наше требование, поскольку она будет работать только в сценарии, когда интерфейсы маршрутизаторов, подключенные к каналу WAN, находятся в состоянии UP/UP или DOWN/DOWN. Но во многих ситуациях мы видим, что, хотя линки остаются работоспособными, но мы не можем достичь шлюза, это обычно происходит, когда проблема находится на стороне провайдера.
В таких случаях IP SLA становится лучшим другом инженера.
Используя IP SLA, Cisco IOS получает возможность использовать эхо-запросы ICMP для идентификации, когда канал WAN отключается на удаленном конце, и, следовательно, позволяет инициировать резервное соединение с альтернативного порта.
IP SLA настроен на пинг цели, такой как общедоступный IP-адрес или адрес в корпоративной сети, или ваш IP-адрес следующего хопа на маршрутизаторе ISP. Пинги маршрутизируются только с основного интерфейса.
Пример конфигурации IP SLA для генерации пинга icmp, нацеленного на IP-адрес следующего перехода ISP1:
R1(config)# ip sla 1
R1(config)# icmp-echo 2.2.2.2 source-interface FastEthernet0/0
R1(config)# timeout 1000
R1(config)# threshold 2
R1(config)# frequency 3
R1(config)# ip sla schedule 1 life forever start-time now
Обратите внимание, что команды Cisco IP SLA меняются в зависимости от версии IOS, и чтобы узнать точную команду для вашей версии IOS, проверьте документацию Cisco. Вышеприведенные команды предназначены для IOS 12.4(4) T, 15.(0)1M и более поздних выпусков.
Приведенная выше конфигурация определяет и запускает IP SLA.
ICMP-echo отправляет эхо-пакет ICMP на IP следующего хопа 2.2.2.2 каждые 3 секунды, как определено параметром “frequency”.
“Timeout” устанавливает время (в миллисекундах), в течение которого операция SLA Cisco IOS IP ожидает ответа от своего пакета запроса.
“Threshold” устанавливает порог, который генерирует событие реакции и хранит хронологическую информацию для операции SLA Cisco IOS IP.
После определения операции IP SLA наш следующий шаг - определить объект, который отслеживает SLA. Это можно сделать с помощью IOS Track Object, как показано ниже:
R1(config)# track 1 ip sla 1 reachability
Приведенная выше команда создает трек, который будет отслеживать состояние операции IP SLA. Если от IP-адреса следующего хопа нет откликов на пинг, трек отключится и начнет работать, когда SLA начнет снова получать пинг-ответ.
Чтобы проверить состояние трека, используйте команду show track, как показано ниже:
R1# show track
Track 1
IP SLA 1 reachability
Reachability is Down
1 change, last change 00:03:19
Latest operation return code: Unknown
Последним шагом в конфигурации надежного статического маршрута IP SLA является добавление оператора отслеживания к маршрутам по умолчанию, указывающим на маршрутизаторы ISP, как показано ниже:
R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10
Добавив после адрес ключевое слово track и его номер, мы указываем, что только если состояние настроенного трека будет Up. Следовательно, если статус трека Down, то вторичный маршрут будет использоваться для пересылки всего трафика.
Готово! Мы успешно настроили автопереключение между двумя провайдерами при помощи IP SLA с icmp-echo