Cisco *

Недавно я столкнулся с проблемой выбора среды для изучения некоторых фич маршрутизаторов Cisco. Раньше я пользовался GNS3, а сейчас решил посмотреть, что изменилось в мире. Как выяснилось, прогресс шагнул далеко вперёд. Погружаясь в пучину статей и форумов, я обнаружил что огромное количество информации из них уже устарело. Чтобы не запутаться в многообразии ПО, я сделал себе небольшую шпаргалку (актуальность — март 2020 г.). Теперь я хочу выложить её на суд общественности. Во-первых, чтобы не пропадала (мне кажется, кому-то это может пригодиться, так как в одном месте я упоминания всех средств разом так и не нашёл). Во-вторых, возможно, в комментариях мне укажут на ошибки в описаниях и это позволит улучшить обзор.

Многие компании переходят на использование облачных сервисов в своем бизнесе по всему миру, это и офисные приложения, сервисы BigData, чат/видео/аудио коммуникация с целью проведения митингов/обучения и многие другие. Однако ввиду массового перевода на удаленную работу сотрудников так или иначе требуется получать доступ к корпоративной сети (если конечно заказчик не полностью работает на облачной платформе), для того чтобы сделать доступ безопасным, как правило, используются сервисы типа Remote-Access VPN.
Классически такие сервисы могут либо полностью направлять весь трафик удаленного клиента в VPN туннель, либо выборочно направлять или исключать из туннеля трафик основываясь на IPv4/IPv6 подсетях.

Многие безопасники решат что наиболее оптимальным было бы использовать опцию полного туннелирования (tunnelall) трафика для полного контроля за всем трафиком пользователя в момент подключения к корпоративной сети и отсутствием возможности параллельного вывода данных через неконтролируемое интернет-соединение. Однако есть и другая чаша весов...

• Как организовать файлообмен Box/Dropbox/SharePoint напрямую в облако со скоростью домашнего канала интернет, минуя медленный корпоративный VPN?
• Как организовать соединение Webex/Skype напрямую с абонентом, не проводя его через HQ VPN-шлюз, создавая задержки связи и снижая качество связи?
• Как заставить только определенные облачные сервисы работать вне VPN туннеля, чтобы пользователь их использовал напрямую через домашний интернет и контролировать остальные не доверенные службы централизованно?
• Как эффективно снизить нагрузку на VPN-шлюз не проводя через него трафик доверенных облачных приложений?

В данной статье я бы хотел привести пошаговую инструкцию того как можно быстро развернуть самую масштабируемую на текущий момент схему Remote-Access VPN доступа на базе AnyConnect и Cisco ASA – VPN Load Balancing Cluster.

Введение: Многие компании во всем мире ввиду текущей обстановки с COVID-19 предпринимают усилия по переводу своих сотрудников на удаленный режим работы. Ввиду массовости перехода на удаленную работу, критическим образом возрастает нагрузка на имеющиеся VPN шлюзы компаний и требуется очень быстрая возможность их масштабирования. С другой стороны, многие компании вынуждены второпях осваивать с нуля такое понятие как удаленная работа.

День добрый. Это вторая часть цикла из двух статей. В первой части мы ловили Zabbix-ом трапы PortSecurity от коммутаторов, а здесь мы, можно сказать, решаем обратную задачу — снимаем блокировку порта коммутатора щелчком мыши в фронтенде Zabbix-а.

Так получилось, что эта задача решалась два раза, двумя разными инструментами и с разницей в несколько месяцев. Сначала использовался Ansible, который вполне успешно справлялся. Но в один прекрасный момент он сломался (опять) и та же самая задача была решена простым Python-ом с использованием широко известной в узких кругах сетевой библиотекой Napalm.

Здравствуй уважаемое хабросообщество!

Решился выплеснуть в онлайн пару in-house решений, которые облегчают деятельность сетевиков и прочих ИТ братьев по разуму.

В этой статье речь пойдет о мониторинге событий стандартного (для многих вендоров) механизма защиты от несанкционированного подключения устройств к сети, — механизма PortSecurity.

Решение изначально построено для коммутаторов от компании Cisco, но при желании легко допиливается под любой коммутатор и под любые события, основанные на SNMP-трапах.

Если интересно, добро пожаловать под кут...

Приветствую, и сперва немного лирики. Я иногда завидую коллегам, работающим удалённо — ведь это прекрасно иметь возможность работать из любого конца подключённого к Internet мира, каникулы в любое время, ответственность за проекты и дедлайны, а не нахождение в офисе с 8 до 17. Моя позиция и рабочие обязанности практически исключают возможность долгого отсутствия в датацентре. Однако — периодически случаются интересные кейсы, подобные описанному ниже — и я понимаю, что существует мало позиций, где есть такой простор для творческого выражения внутреннего troubleshooter'а.

Пришло время сделать так чтобы корпоративные сервисы связи были доступны вне офиса без дополнительных телодвижений со стороны пользователя вроде использования приложения Cisco Anyconnect и/или установки дополнительных VPN-туннелей.

В этом выпуске я покажу и объясню, как настроить Cisco Expressway сервера чтобы видеоконференцсвязь работала не только внутри, но и за пределами вашей организации.

Привет, Хабр!

Недавно тут проскочила статья Mikrotik и Linux. Рутина и автоматизация где подобную задачу решали ископаемыми средствами. И хотя задача совершенно типовая, на Хабре про нее как то ничего подобного и не находится. Осмелюсь предложить уважаемому ИТ-сообществу свой велосипед.

— Да этот ЦОД можно развернуть и настроить, пока ты пиццу заказываешь!

Я бросил эти слова на совещании, и расплата пришла немедленно. Коллега предложила заказать пиццу. Оплачивает проигравший: если я успеваю собрать ЦОД — то она, если не успеваю — то я.

Чёрт!

В общем, встречайте стресс-тест: гиперконвергентное решение от Cisco с простой настройкой против приготовления пиццы.

Всем привет! Спустя продолжительное время возвращаемся к циклу статей. Долгое время мы разбирали мир коммутации и узнали о нем много интересного. Теперь пришло время подняться чуть повыше и взглянуть на сторону маршрутизации. В данной статье поговорим о том, зачем нужна маршрутизация, разберем отличие статической от динамической маршрутизации, виды протоколов и их отличие. Тема очень интересная, поэтому приглашаю всех-всех к прочтению.

Это миф, достаточно распространённый в сфере серверного железа. На практике же гиперконвергентные решения (когда всё в одном) нужны много для чего. Исторически сложилось, что первые архитектуры были разработаны Amazon и Google под свои сервисы. Тогда идея была в том, чтобы сделать вычислительную ферму из одинаковых узлов, у каждого из которых есть собственные диски. Всё это объединялось неким системообразующим софтом (гипервизором) и разбивалось уже на виртуальные машины. Главная задача — минимум усилий на обслуживание одного узла и минимум проблем при масштабировании: просто докупили ещё тысячу-другую таких же серверов и подключили рядом. На практике это единичные случаи, и гораздо чаще речь про меньшее число узлов и немного другую архитектуру.

Но плюс остаётся тем же — невероятная простота масштабирования и управления. Минус — разные задачи по-разному потребляют ресурсы, и где-то локальных дисков будет много, где-то мало оперативки и так далее, то есть при разном типе задач будет падать утилизация ресурсов.

Получалось, что вы платите на 10–15% больше за удобство настройки. Это и вызвало миф из заголовка. Мы долго искали, где же будет применяться технология оптимально, и нашли. Дело в том, что у Циски не было своих СХД, но они хотели полный серверный рынок. И они сделали Cisco Hyperflex — решение с локальными хранилищами на нодах.

А из этого внезапно получилось очень хорошее решение для резервных дата-центров (Disaster Recovery). Почему и как — сейчас расскажу. И покажу тесты кластера.

Привет. У нас 15 260+ объектов и 38 000 сетевых устройств, которые нужно настраивать, обновлять и проверять их работоспособность. Обслуживать такой парк оборудования довольно сложно и требует много времени, сил и людей. Поэтому нам потребовалось автоматизировать работу с сетевым оборудованием и мы решили адаптировать концепцию Network as a Code для управления сетью в нашей компании. Под катом читайте нашу историю автоматизации, совершенные ошибки и дальнейший план построения систем.

Сегодня мы рассмотрим, как устранять неполадки реализации протокола EIGRP. Для этого вам нужно загрузить лабораторную работу на эту тему по ссылке www.nwking.org/product/resources-day-51-eigrp-troubleshooting, которая приведена под данным видео, а затем мы вместе займемся её выполнением.

Мы все ещё продолжаем тематику раздела 2.6 курса ICND2, и как я сказал, вам следует зайти на сайт и скачать лабораторную работу «День 51: устранение неполадок EIGRP», которая представляет собой заархивированный файл для программы Cisco Packet Tracer.



Я уже выполнил начальные настройки в этой лабораторной работе так, чтобы мы смогли рассмотреть устранение наиболее типичных неполадок конфигурации протокола, еще 3 месяца назад. С тех пор у меня не было времени закончить этот видеоурок, поэтому я подзабыл, о каких именно неполадках идет речь.

Сегодня мы продолжим изучение раздела 2.6 тематики курса ICND2 и рассмотрим настройку и проверку протокола EIGRP. Настройка EIGRP очень проста. Как и в любом другом протоколе маршрутизации типа RIP или OSPF, вы заходите в режим глобальной конфигурации роутера и вводите команду router eigrp <#>, где # — номер автономной системы AS.



Этот номер должен совпадать для всех устройств, например, если у вас имеется 5 роутеров и все они используют EIGRP, то у них должен быть одинаковый номер автономной системы. В OSPF это Process ID, или номер процесса, а в EIGRP – номер автономной системы.

Сегодня мы начнем изучение протокола EIGRP, которое наравне с изучением OSPF является важнейшей темой курса CCNA.



Позже мы вернемся к разделу 2.5, а сейчас сразу после раздела 2.4 перейдем к разделу 2.6 «Настройка, проверка и устранение неполадок EIGRP по протоколу IPv4 (за исключением аутентификации, фильтрации, ручного суммирования, перераспределения и конфигурации stub)».
Сегодня у нас будет вводный урок, на котором я расскажу вам о концепции усовершенствованного внутреннего протокола маршрутизации шлюзов EIGRP, а на двух следующих уроках мы рассмотрим настройку и устранение неполадок роботы данного протокола. Но сначала я хочу сообщить вам следующее.

Сегодня мы рассмотрим вопрос настройки протокола OSPFv2 IPv4 для нескольких зон, который входит в раздел 2.4 тематики ICND2. Мы будем работать с топологией сети, в состав которой входит 7 роутеров, и шесть из них работают по протоколу OSPF. Роутер №7, расположенный в самом низу, работает по протоколу RIPv2.



На предыдущих уроках мы рассматривали сети, в которых все OSPF-устройства работали в одной общей зоне. Сейчас мы будем работать с несколькими отдельными зонами.

Роутеры R1 и R6 принадлежат зоне 45, роутер R5 работает в зоне 12. Это внутренние роутеры, обслуживающие локальные сети. Роутеры R2 и R4 являются пограничными маршрутизаторами ABR. Это роутеры, которые осуществляют связь роутеров остальных зон regular area с корневой, или опорной зоной backbone area, номер которой всегда равен 0.

Сегодня мы продолжим тему предыдущего урока о протоколе OSPF, которому посвящен раздел 2.4 тематики ICND2, и рассмотрим устранение типичных проблем реализации этого протокола. Вернемся к примеру Packet Tracer, которым мы закончили последнее видео. Для начала я исправлю обозначение сети между роутерами R1 и R5, здесь должно быть другое значение – 10.1.1.0/24.



Вы могли скачать этот пример по ссылке, приведенной под видеоуроком «День 46», и если не сделали этого, то можете скачать его сейчас в качестве задачи по устранению неполадок OSPF.
Задача такова: PC0 должен пропинговать PC1 и PC2, а компьютеры PC1 и PC2 должны иметь возможность пинговать друг друга.

Сегодня мы продолжим тему предыдущего урока о настройках и проверке работы протокола OSPF, которым посвящен раздел 2.4 тематики ICND2. Проверка работы протокола очень важна, так что вы должны знать, какие команды нужно для этого использовать. Прежде чем начать этот урок, я хочу извиниться перед вами за ошибку, которую допустил в предыдущем видео. Говоря о выборе DR и BDR, я упоминал о случаях, когда совпадают идентификаторы процесса Process ID разных роутеров. Так вот, совпадают не номера процессов, а приоритеты OSPF-интерфейса роутеров. Если такое происходит, то выбор DR осуществляется на основе сравнения идентификаторов роутеров Router ID.



Я не успеваю перезаписать предыдущее видео, так как спешу закончить поскорее весь курс, поэтому еще раз извиняюсь за допущенную ошибку. Обычно я заменяю видео, если замечаю в нем ошибки. Однако я просмотрел предыдущее видео только перед публикаций этого урока, так что заметил ошибку слишком поздно, ведь с момента публикации урока «День 45» прошло уже 2 месяца. К сожалению, никто не указал мне на эту ошибку в комментариях.

На прошло видеоуроке мы изучили раздел 2.4 тематики ICND2, где я в очень доступной манере рассказал, как работает протокол OSPF, как формируются соседские отношения роутеров и создаются таблицы маршрутизации. Сегодня мы ещё немного рассмотрим теорию вопроса, после чего перейдём к Packet Tracer и займемся настройкой топологии сети.

Когда мы говорим об общей среде Shared medium, то чаще всего имеем в виду Интернет. Рассмотрим сеть, состоящую из 4-х роутеров, каждый из которых подключен к свитчу. Свитч представляет собой общую широковещательную среду, потому что благодаря свитчу сообщение, отправленное роутером R1, будут «слышать» все остальные устройства.



Все маршрутизаторы представляют собой OSPF-устройства, настроенные на восприятие мультикастового адреса. В этом заключается проблема, потому что в данной сети образуется слишком много трафика, ведь каждый роутер стремится поделиться с остальными всеми маршрутами, которые ему известны. Синхронизация LSDB затрачивает огромный объем трафика, это крайне неэффективное использование каналов связи и пустая трата пропускной способности. OSPF решает эту проблему, выбрав в широковещательном домене один из роутеров в качестве выделенного маршрутизатора Designated router D.R, а другой – в качестве резервного выделенного маршрутизатора Backup designated router, B.D.R. При этом роутеры делятся базами не каждый с каждым, а передают свои LSDB только DR, а тот уже делится ими с остальными устройствами. При этом сетевой трафик при использовании OSPF сокращается в разы.

Сегодня мы начнем изучение маршрутизации по протоколу OSPF. Эта тема, как и рассмотрение протокола EIGRP, является важнейшей во всем курсе CCNA. Как видите, раздел 2.4 называется «Настройка, проверка и неполадки единичной зоны и мультизоны OSPFv2 для протокола IPv4 (за исключением аутентификации, фильтрации, ручного суммирования маршрутов, перераспределения, тупиковой области, виртуальной сети и LSA)».



Тема OSPF достаточно обширна, поэтому она займет 2, возможно, 3 видеоурока. Сегодняшний урок будет посвящен теоретической стороне вопроса, я расскажу вам, что представляет собой этот протокол в общих чертах и как он работает. В следующем видео мы перейдем к режиму конфигурации OSPF с помощью Packet Tracer.