По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Третья статья будет посвящена поиску и устранению неисправностей EtherChannels. Большинство проблем с EtherChannels происходит из-за неправильной конфигурации. Предыдущие статьи этого цикла: Устранение неполадок коммутации Cisco Траблшутинг STP (Spanning tree protocol) Case #1 В этом сценарии есть только два коммутатора и два интерфейса. Идея состоит в том, чтобы сформировать etherchannel путем объединения интерфейсов FastEthernet 0/13 и 0/14, но это не работает Сначала мы проверим, все ли интерфейсы работают. Да они все работают. Мы можем проверить, что port-channel interface был создан, но он не работает. Вот хорошая команда для проверки EtherChannel. Используйте суммарную информацию от команды show etherchannel summary, чтобы увидеть ваши port-channels. Мы видим, что коммутатор A настроен для LACP и коммутатор B для PAgP, а это никогда не будет работать. Лучшая команда для использования это show etherchannel detail. Это дает вам много информации, но нам особенно интересно узнать, настроен ли LACP для пассивного или активного режима. Интерфейсы в активном режиме будут "активно" пытаться сформировать EtherChannel. Интерфейсы в пассивном режиме будут отвечать только на запросы LACP. Вот вывод команды show etherchannel detail на коммутаторе B. Мы видим, что он был настроен для PAgP, и интерфейсы настроены для desirable режима. Если бы они были настроены на автоматический режим, мы бы увидели флаг А. SwitchB(config)#no interface po1 SwitchB(config)#interface fa0/13 SwitchB(config-if)#channel-group 1 mode passive SwitchB(config-if)#exit SwitchB(config)#interface fa0/14 SwitchB(config-if)#channel-group 1 mode passive Давайте сначала избавимся от port-channel interface. Если мы этого не сделаем, вы увидите ошибку при попытке изменить channel-group mode на интерфейсах. После изменения конфигурации мы видим, что port-channel1 поднялся. Задача решена! Извлеченный урок: убедитесь, что вы используете один и тот же режим EtherChannel с обеих сторон. Case #2 Ну что же давайте рассмотрим другую ошибку! Та же топология и EtherChannel, который не функционирует: Мы проверяем, что port-channel interface существует, но он не работает с обеих сторон. Мы также видим, что интерфейс FastEthernet 0/13 и 0/14 были добавлены к port-channel interface. Интерфейсы FastEthernet рабочие, поэтому мы знаем, что проблема не в этом. Давайте углубимся в конфигурацию EtherChannel. Мы видим, что FastEthernet 0/13 и 0/14 на коммутаторе A оба настроены на автоматический режим PAgP (из-за флага "A"). FastEthernet 0/13 и 0/14 на коммутаторе B также настроены на автоматический режим PAgP. Это никогда не сбудет работать, потому что оба коммутатора теперь пассивно ждут сообщений PAgP. SwitchB(config)#interface fa0/13 SwitchB(config-if)#channel-group 1 mode desirable SwitchB(config-if)#interface fa0/14 SwitchB(config-if)#channel-group 1 mode desirable Давайте изменим один из коммутаторов, чтобы он активно отправлял сообщения PAgP. EtherChannel сейчас работает. Проблема решена! Извлеченный урок: при использовании PAgP убедитесь, что хотя бы один из коммутаторов использует требуемый режим, или в случае LACP убедитесь, что один коммутатор находится в активном режиме. Case #3 Еще одна ситуация: EtherChannel настроен между коммутатором A и коммутатором B, но клиент жалуется, что соединение медленное ... что может быть не так? Быстрая проверка говорит нам, что port-channel interface работает. Команда show etherchannel detail дает нам много выходных данных, но она так же нам говорит, что происходит. Вы видите, что интерфейс FastEthernet 0/13 и 0/14 были настроены для port-channel, но коммутатор не смог связать их, потому что FastEthernet 0/14 настроен на 10 Мбит. Возможно, что это основная причина медленной скорости передачи данных. Мы будем использовать один из операторов для команды show. Нас интересует только то, чтобы увидеть вероятную причину, которую команда "show etherchannel detail" покажет. SwitchA(config)#interface fa0/14 SwitchA(config-if)#speed auto SwitchB(config)#interface fa0/14 SwitchB(config-if)#speed auto Давайте изменим скорость на авто. Мы должны убедиться, что FastEthernet 0/13 и 0/14 имеют одинаковую конфигурацию. Вероятно, вы увидите пару сообщений о том, что ваши интерфейсы переходят в состояние up и down. Теперь мы видим, что оба интерфейса были добавлены в port-channel... проблема решена! Извлеченный урок: убедитесь, что все интерфейсы, которые будут добавлены в port-channel, имеют одинаковую конфигурацию!
img
Само слово состоит из двух частей - Dev (Development), то есть разработка и Ops (Operations) - эксплуатация. Разработка и эксплуатация. Ок, запомнили. Но что это конкретно? Танец? Напиток? Профессия? Не совсем, девопс - это модель взаимодействия тех, кто пишет код с теми, кто этот код заставляет работать - раскатывает в продакшн, управляет серверами, сетью и вот этим вот всем. Такая профессия называется ДевОпс-инженер Любая компания, которая делает деньги на разработке программного обеспечения, хочет быстро расти, быть технологичнее и быстрее своих конкурентов, при это не забывать о наличии печенек и вкусного чая на кухне в офисе. У серьезных компаний большая и сложная инфраструктура: куча серверов, коммутаторов, маршрутизаторов, и все это еще и раскидано географически по миру. А чтобы код их приложения заработал у пользователей, без лагов, багов и задержек, нужно учесть кучу факторов! До появления методологии DevOps, при разработке, могли возникать случаи, когда что-то не работает, или работает не так, как хотелось бы: «Мой код превосходен, а сервера сконфигурированы хреново, а еще ваша сеть, кхм-кхм, - говно» - говорит разработчик «Сеть работает отлично, задержка в пределах нормы, а вы там что то наговнокодили» - парирует администратор И понеслась. У сетевого администратора не хватало компетенций и информации о том как надо настраивать сервера, в результате чего приходилось подключать для этого разработчиков, у которых в свою очередь не было компетенций админов. Короче, ДевОпс инженер это по сути системный администратор который работает с программным обеспечением, серверами и сетью, а также понимает как происходит процесс разработки и умеет программировать. Новый виток эволюции админа, который умеет больше и, конечно, получает больше денег. Девопс исключит перекидывание мячика из отдела разработки к администраторам, значительно ускорит релизы новых фич и исправлений в продукте, откроет дорогу к легкому масштабированию и повышению надежности инфраструктуры, превратит вашу разработку в полноценный конвейер, даст прохладу, влажность и, скорее всего, силу земли Итак, вот базовые вещи, которые должен знать девопс инженер: Легко ориентироваться в Windows и Linux операционных системах - кстати, по ним у нас есть собственные курсы и никто не помешает тебе пройти бесплатный вводный урок по ссылке. Нужно знать сетевые технологии на уровне Cisco CCNA - вот это совпадение! У нас также есть большой курс по сетевым технологиям, который поможет тебе познать самые нужные сетевые аспекты работы DevOps. ДевОпс должен знать инструменты для управления конфигурацией и автоматизации серверов Chef, Puppet, Ansible. И уметь писать скрипты. Ну минимум на Python. Зачем это надо? Как раз чтобы работать с этими инструментами. Этого достаточно, чтобы уже получать в среднем по РФ 100-200 тысяч рублей! Ну и как видавшие девопсов добавим, что будет отлично так же знать: Про непрерывную интеграцию и доставку (CI/CD) – сборка и тестирование конечного продукта (Jenkins, TeamCity, Bamboo) Распределенный контроль версий (Git, Mercurial, Subversion, CVS) Контейнеризацию и оркестровку (Docker, Kubernetes, Docker Swarm) Управление инфраструктурой как кодом (Puppet, Chef, Ansible, Salt) Виртуализацию (Vagrant, VMware) Подробнее об этих и других инструментах можно прочитать в этой статье.
img
В сегодняшней статье рассмотрим один из самых важных модулей Asterisk, который является необходимым инструментом в решении проблем со звонками (траблшутинга), статистики и отчётности. Речь пойдёт о модуле CDR Reports. Все примеры, традиционно, будем приводить на нашем FreePBX 13 /p> CDR (Call Detailed Record) – это подробная запись об акте коммутации (звонке), которые были проведены на телефонной станции. Такие записи есть практически у любой существующей цифровой АТС. Каждый производитель цифровой АТС предлагает свои сервисы для просмотра CDR. В Asterisk это модуль CDR Reports. Модуль CDR Reports позволяет формировать мгновенные отчёты о телефонных звонках, которые так или иначе проходили через Вашу IP-АТС. Это могут быть как внутренние звонки между сотрудниками компании, так и звонки из/во “внешний мир", Asterisk записывает всё. Можно посмотреть, как полную историю звонков, так и создать уникальный отчёт, отфильтровав записи по дате, временным интервалам, только исходящим звонкам, только по определенным номерам CID и так далее. Звонки, которые появятся в сформированном отчёте, можно прослушать прямо из модуля. Важно отметить, что модуль CDR Reports требует, чтобы CDR – записи хранились в базе данных. О том, как Asterisk записывает детализирует телефонные события, вы можете прочитать в статье про cистему CEL (Channel Event Logging) Для формирования вышеупомянутых отчётов, модуль CDR Reports имеет интерфейс. Нужно отметить, что неопытному пользователю может быть трудно работать с интерфейсом, поскольку он имеет множество опций, с которыми не все знакомы. Однако, напротив каждой опции предусмотрены подсказки, подробно описывающие для чего они нужны. Рассмотрим интерфейс на примере FreePBX 13. Для того, чтобы в него попасть, с главной страницы переходим по следующему пути Reports - > CDR Reports, как показано на рисунке. Перед нами открывается интерфейс модуля CDR Reports с множеством фильтров Как видно, благодаря имеющимся фильтрам можно создавать самые разные отчёты. Коротко рассмотрим каждый фильтр: Call Date – Дата звонка. Справа можно выбрать временной промежуток, который нас интересует CallerID Number – Номер звонящего. Выводит все записи по определенному интересующему номеру телефона. Можно ввести множество номеров, разделяя их запятыми. Справа можно выбрать условия совпадения – “Начинается с", “Содержит", “Заканчивается на" и “Совпадает точно" данные условия можно применить и для остальных фильтров CallerID Name – Имя звонящего Outbound CallerID Number – Номер, с которого звонят, при исходящем звонке DID – Искать по набранному номеру. Это удобно, когда в компании несколько входящих линий Destination –Искать по номеру назначения. Например, когда звонок переведен на внутреннего сотрудника или звонок попал на Ring группу Destination CallerID Name – Искать по имени, присвоенного номеру назначения Userfield – Искать по полю Userfield, если оно включено на Extension’е Account Code – Искать по Аккаунт коду Duration – Продолжительность звонка. Справа можно выбрать интервал в секундах Disposition – Искать по характеру обработки вызова. Например: ANSWERED, BUSY, NO ANSWER. Позволяет найти не отвеченные звонки, звонки которые были приняты, звонки, которые не были приняты по причине занятости абонента Также записи можно сгруппировать по различным параметрам при помощи опции Group By Как только все нужные фильтры заполнены интересующими входными данными, необходимо нажать клавишу Search, чтобы сформировался отчёт Интерфейс статистики Merion Metrics Как видите, стандартный модуль CDR Report содержит очень много различных фильтров и параметров, которые, зачастую, просто не нужны рядовому пользователю. Именно поэтому, мы создали свой собственный интерфейс построения отчётов для Asterisk, интуитивно понятный и упрощенный. Наша разработка обладает не только базовым функционалом модуля CDR Report, но также позволяет формировать визуализированные отчёты и диаграммы. Посмотрите видео о том, как много радости приносит наш интерфейс статистики для IP - АТС Asterisk: Интерфейс можно попробовать бесплатно, пройдя по ссылке -
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59