— Да этот ЦОД можно развернуть и настроить, пока ты пиццу заказываешь!
Я бросил эти слова на совещании, и расплата пришла немедленно. Коллега предложила заказать пиццу. Оплачивает проигравший: если я успеваю собрать ЦОД — то она, если не успеваю — то я.
Чёрт!
В общем, встречайте стресс-тест: гиперконвергентное решение от Cisco с простой настройкой против приготовления пиццы.Читать полностью »
Это миф, достаточно распространённый в сфере серверного железа. На практике же гиперконвергентные решения (когда всё в одном) нужны много для чего. Исторически сложилось, что первые архитектуры были разработаны Amazon и Google под свои сервисы. Тогда идея была в том, чтобы сделать вычислительную ферму из одинаковых узлов, у каждого из которых есть собственные диски. Всё это объединялось неким системообразующим софтом (гипервизором) и разбивалось уже на виртуальные машины. Главная задача — минимум усилий на обслуживание одного узла и минимум проблем при масштабировании: просто докупили ещё тысячу-другую таких же серверов и подключили рядом. На практике это единичные случаи, и гораздо чаще речь про меньшее число узлов и немного другую архитектуру.
Но плюс остаётся тем же — невероятная простота масштабирования и управления. Минус — разные задачи по-разному потребляют ресурсы, и где-то локальных дисков будет много, где-то мало оперативки и так далее, то есть при разном типе задач будет падать утилизация ресурсов.
Получалось, что вы платите на 10–15% больше за удобство настройки. Это и вызвало миф из заголовка. Мы долго искали, где же будет применяться технология оптимально, и нашли. Дело в том, что у Циски не было своих СХД, но они хотели полный серверный рынок. И они сделали Cisco Hyperflex — решение с локальными хранилищами на нодах.
А из этого внезапно получилось очень хорошее решение для резервных дата-центров (Disaster Recovery). Почему и как — сейчас расскажу. И покажу тесты кластера. Читать полностью »
Сегодня мы рассмотрим, как устранять неполадки реализации протокола 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 – номер автономной системы.Читать полностью »
Сегодня мы рассмотрим вопрос настройи протокола OSPFv2 IPv4 для нескольких зон, который входит в раздел 2.4 тематики ICND2. Мы будем работать с топологией сети, в состав которой входит 7 роутеров, и шесть из них работают по протоколу OSPF. Роутер №7, расположенный в самом низу, работает по протоколу RIPv2.
На предыдущих уроках мы рассматривали сети, в которых все OSPF-устройства работали в одной общей зоне. Сейчас мы будем работать с несколькими отдельными зонами.
Роутеры R1 и R6 принадлежат зоне 45, роутер R5 работает в зоне 12. Это внутренние роутеры, обслуживающие локальные сети. Роутеры R2 и R4 являются пограничными маршрутизаторами ABR. Это роутеры, которые осуществляют связь роутеров остальных зон regular area с корневой, или опорной зоной backbone area, номер которой всегда равен 0. Читать полностью »
Итак, я продолжу статью, посвященную мониторингу безопасности облачных провайдеров. В первой части я рассказывал об опыте Cisco в работе с внешними облачными сервисами, а также о наблюдениях Cisco, с которым мы столкнулись при построении или аудите SOCов наших заказчиков. Взяв в первой части в качестве примера три самых популярных решения от компаний Amazon, Microsoft и Google, которые являются IaaS/PaaS-платформами, сегодня наступила пора поговорить о мониторинге SaaS-платформ — Dropbox, Salesforce.com, Slack и Apple Business Manager, а также о том, какие SIEM сегодня лучше всего подходят для мониторинга облачных платформ.
Если на базе AWS, Azure или GCP вы можете создать почти полный аналог своей корпоративной инфраструктуры, только в облаке, то есть облачные сервисы, которые выполняют одну конкретную задачу, например, файловое хранилище, как это делает Dropbox. Этот сервис давно вышел за рамки обычной пользовательской хранилки, предоставляя своим корпоративным пользователям целый набор защитных механизмов:
Сегодня мы продолжим тему предыдущего урока о настройках и проверке работы протокола 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 сокращается в разы.Читать полностью »
Сегодня мы рассмотрим маршрутизацию Inter-VLAN и виртуальный интерфейс свитча SVI. Мы уже знакомились с этими темами в курсе ICND1 и сейчас займемся ими более углубленно. Эти темы упоминаются в разделе 2.0 «Технологии маршрутизации» курса ICND2, подразделы 2.1а и 2.1b. Сначала мы рассмотрим настройку, проверку и неполадки маршрутизации Inter-VLAN, затем концепцию архитектуры сети Router-on-a-Stick (ROAS) и интерфейс свитча SVI.
Перейдем к программе Packet Tracer и рассмотрим, что представляет собой виртуальный интерфейс свитча SVI. На схеме показано две сети: отдела продаж и отдела маркетинга, каждая из которых имеет свой свитч. По умолчанию компьютеры подсоединяются к свитчу через дефолтную VLAN1, поэтому без проблем могут связываться друг с другом.
Но если компьютер №1 отдела продаж захочет связаться с компьютером №1 отдела маркетинга, он не сможет этого сделать, потому что сети не соединены. Технически можно соединить кабелем оба свитча, но компьютеры все равно не смогут связаться, потому что являются частями разных сетей с разным диапазоном IP-адресов – 192.168.10.0/24 и 192.168.20.0/24. Читать полностью »
Сегодня мы рассмотрим две важные темы: DHCP Snooping и «недефолтные» Native VLAN. Перед тем, как перейти к уроку, приглашаю вас посетить другой наш канал YouTube, где вы сможете просмотреть видео о том, как улучшить свою память. Рекомендую вам подписаться на этот канал, так как там мы размещаем множество полезных советов для самоусовершенствования.
Этот урок посвящен изучению подразделов 1.7b и 1.7с тематики ICND2. Перед тем, как приступить к DHCP Snooping, давайте вспомним некоторые моменты из предыдущих уроков. Если я не ошибаюсь, мы изучали DHCP на уроках «День 6» и «День 24». Там обсуждались важные вопросы, касающиеся назначения IP-адресов DHCP-сервером и обмена соответствующими сообщениями.
Обычно, когда конечный пользователь End User входит в сеть, он посылает в сеть широковещательный запрос, который «слышат» все сетевые устройства. Если он напрямую соединен с DHCP-сервером, то запрос поступает непосредственно на сервер. Если же в сети имеются передаточные устройства – роутеры и свитчи – то запрос серверу проходит через них. Получив запрос, DHCP-сервер отвечает пользователю, тот посылает ему запрос на получение IP-адреса, после чего сервер выдает такой адрес устройству пользователя. Именно так происходит процесс получения IP-адреса в нормальных условиях. Согласно примеру на схеме, End User получит адрес 192.168.10.10 и адрес шлюза 192.168.10.1. После этого пользователь сможет выходить через этот шлюз в интернет или связываться с остальными сетевыми устройствами. Читать полностью »
