Cisco *

Disclaimer: только для гиков; устаревшая технология; статья в режиме “just for fun”.

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

Эта статья логическое окончание темы EVPN в сети VxLAN, посвященное запуска группы "Дизайн сетей ЦОД" от OTUS. Сегодня постараюсь закрыть тему выбора между iBGP и eBGP в overlay сети.

Миграция платежной системы в облако: Зачем и стоит ли?

Привет! Наша компания занимается разработкой платформы для процессинга электронных платежей. Платформа предоставляется в аренду по White-label модели другим компаниям, которые хотят начать бизнес в области процессинга электронных платежей, при этом получив ряд “плюшек”:

- быстрый запуск;

- готовая PCI DSS ready инфраструктура;

- дополнительная поддержка, в том числе при прохождении аудита PCI DSS;

- брендирование;

- гибкая цена.

В данной статье мы хотели бы поделиться своим опытом перехода на облачную микросервисную архитектуру, обозначить с практической точки зрения плюсы такого подхода. Материал в равной степени будет интересен как начинающим специалистам DevOps, которые хотят получить базовые представления о построении комплексных самостоятельных облачных систем, так и техническим специалистам финтех компаний, которые столкнулись с ограничениями архитектуры своих существующих решений.

Будучи одними из первопроходцев на рынке решений для процессинга электронных платежей, мы построили архитектуру платформу на базе популярных на тот момент (примерно 2012 год) и хорошо зарекомендовавших себя решений - PCI DSS ready инфраструктура с аппаратными межсетевыми экранами Cisco ASA, с сегментацией сети, использовались отдельные хосты для каждой роли - фронтенд с админкой, платежными формами, API и incoming/outgoing прокси; процессинг; хосты выдачи вакантных ключей для шифрования карточных данных; хосты с реляционными БД и т.д. Стек был тоже достаточно традиционный - PHP, Apache, MySQL.

Есть теория, что если долбить в php file_get_contents()'ом Гугло-Яндексы с редким интервалом, то они медленно, но верно, будут давать выдачу без запроса каптчи. Конечно это ничто. Но это примитивно и со временем можно нарастить неплохую базу.

Я рискнул это проверить. Получился неплохой результат. Используем свободный хостинг с базой данных. В качестве объекта воздействия я неслучайно выбрал всеми обожаемые (в том числе и зоркомнадросом) "фильмы о любви". Да-да, те самые. Сентименты и романтика!

В процессе разработки основного скрипта потребовалось сохранять некоторые значения глобально. Выбрал способ писать конфиг в строчку таблицы базы через синглтон настроек. Пример класса приводить не буду. Все стандартно и неинтересно, но у кого есть желание - прошу в репу, где весь проект в открытом доступе.

Основная функция проекта - updateBase(...). Она принимает одну или несколько строк url с запросами к Яндекс или Google по заданной тематике блокировки. Она помещает в базу все адреса первой страницы поисковой выдачи. Для любовной лирики, это например:

Итак, у вас есть длинные лабораторки, которые делаются уже не одну неделю. Каждый день вы что-то добавляте и вам уже достаточно трудно сориентироваться: что и на каком этапе было добавлено, как называются те или иные устройства. Конечно у вас уже есть копия вашего GIT, и часто приходится прыгать между лабами/конфигами и т.п. И вдруг вам надо добавить на похожие хосты похожие куски конфигов, но вы уже подзапутались какое имя было у того верхнего левого роутера или нижнего правого ACCESS свича...Если знакомая ситуация - читайте дальше, Шура.

В стек Cisco C2960X можно объединить до 8 членов, однако мастером стека может быть только один. Добавление коммутатора в стек без некоторых мер предосторожности может привести к катастрофическим последствиям.

Предварительные условия

Для начала, все члены стека должны иметь один образ программного обеспечения Cisco IOS и одинаковый набор функций.

Не все образы программного обеспечения способны быть частью стека: 

Стекирование не поддерживается на коммутаторах, на которых установлен образ LAN Lite.

И, наконец, можем ли мы одновременно использовать разные серии C2960?

Да, поддерживаются все модели C2960X. Вы также можете смешивать в одном стеке C2960X и C2960S, но есть некоторые ограничения. Об этом ниже.

Небольшая заметка о том, что происходит "под капотом" MLS (Multi Layer Switch) Cisco при создании routed интерфейсов.

В MLS интерфейс может находиться в одном из двух режимов:

• "switchport"
• "routed interface" или "no switchport"

При переводе интерфейса в последний, коммутатор позволяет присвоить ip address непосредственно порту и использовать его как интерфейс маршрутизатора.

Однако это всего лишь абстракция. Вот что происходит "под капотом" MLS при переводе интерфейса в режим "no switchport":

Когда у вас одна сетевая розетка, а вам нужно подключить компьютер, принтер, телефон кофеварку и раздать Wi-Fi, на помощь придёт 1815W. Небольшой обзор точки доступа Cisco Aironet 1815W.

На волне проходящего марафона Cisco "Новая классика WLAN", хотелось бы рассказать, как я переводил беспроводную сеть с Cisco 5508 на Cisco Catalist 9800-CL в далеком 2019 году, когда это ещё не было мейнстримом.

Иногда можно наткнуться на такое поведение по умолчанию, обнаружение и понимание которого требует определённой медитации. Для меня одной из таких особенностей была команда “bgp redistribute-internal”. Первоначально назначение этой функции не вызывало у меня каких-либо вопросов, как и то, что её использование может привести к петлям маршрутизации; раз знающие люди написали, что может, значит, так оно и есть. Однако спустя неопределённое время в голове начало скрестись желание получить наглядный пример такой петли. Беглый поиск, впрочем, не дал ничего конкретного.

Бывает так, что приходится сталкиваться с задачами, к решению которых ты вроде бы и не готов, а получить результат надо здесь и сейчас. Знакомо, да? Добро пожаловать в мир восточноевропейского менеджмента с соответствующей культурой управления.

Итак, допустим, ты представитель местечкового провайдера, уже знающий, как настроить какой-нибудь ASUS, но волею судьбы ещё не получивший сертификат CCNA. Рядом с тобой стоит местный админ, тоже без сертификата, глазами молящий ничего не "сбрасывать в ноль", ибо "всё работает, я просто не знаю пароль, только вы никому не говорите".

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

Проведём же вместе сеанс чёрной айтишной магии с последующим её разоблачением. А именно : сбросим пароль, настроим интерфейсы (локальный и внешний), соединим эти сети маршрутами и трансляцией адресов и прикроем(нет) фаерволом. Кирпич с фирменным шильдиком волшебным образом превратится в полезное сетевое устройство.

DMVPN является известным решением для построения топологий hub&spoke. В ряде случаев может понадобиться поддержка изолированной передачи трафика различных клиентов. Конечно, можно построить DMVPN туннель в каждом VRF; однако в реальной жизни такой подход не является достаточно масштабируемым. В такой ситуации на ум приходит MPLS, который зарекомендовал себя в корпоративных и провайдерских сетях.

GRE поддерживает инкапсуляцию различных PDU, в том числе и MPLS, поэтому, на первый взгляд, не должно возникнуть проблем на уровне передачи трафика. С управляющими протоколами, однако, ситуация обстоит несколько сложнее. LDP и RSVP должны установить соседство перед тем, как обменяться какими-либо данными. Масштабируемость этих протоколов обусловлена использованием мультикаста для обнаружения соседей и обмена с ними необходимыми параметрами протокола. Ручная настройка LDP/RSVP соседства в DMVPN сведёт на нет масштабируемость, поэтому такой сценарий статья не рассматривает. Использование же мультикаста ограничивает функциональность решения, поскольку spoke могут обмениваться такими сообщениями только с hub, что исключает наличие spoke-to-spoke связности с использованием MPLS.

Wi-Fi 6 (или 802.11 ax) новый стандарт беспроводных сетей. Новый формат, который создавался с целью исправить баги прошлых стандартов. К 2021-му году у WiFi накопилось достаточно нерешенных проблем. О решении этих проблем и пойдет речь.

Привет, Хабр! Наконец заканчиваю цикл статей, посвященных запуску курса "Архитектор сетей" от OTUS, по технологии VxLAN EVPN. И сегодня обсудим реализацию подключений различных ЦОД или сайтами.

Про настройку и диагностику технологии DMVPN в интернете написано немало статей. Однако про использование мультикаста поверх DMVPN лучшее, что мне удалось найти – это маленькая заметка в Configuration Guide.

“In DMVPN, it is recommended to configure a Rendezvous Point (RP) at or behind the hub. If there is an IP multicast source behind a spoke, the ip pim spt-threshold infinity command must be configured on spokes to avoid multicast traffic going through spoke-to-spoke tunnels.”

Давайте выясним, в чем на самом деле заключается необходимость этой команды.

Данная статья является переводом конкретного раздела, описывающего базовые операции над IPv6-адресами из учебника CCNA 200-301 Volume 1 от автора Wendell Odom.

Мы рассмотрим такие операции как:

1. Сокращение IPv6 адресов
2. Нахождение части подсетей IPv6-адреса
3. Научимся понимать механизм по автоматической выдаче IPv6 адресов на основе MAC-адреса хостов

OSFP, будучи link-state протоколом, исключает петли в топологии за счёт построения дерева кратчайшего пути. Впрочем, тёмный гений изобрёл инструмент разрушения стройной идеи OSPF – речь пойдёт о функции OSPF Virtual Link.

EIGRP – это дистанционно-векторный протокол маршрутизации, изначально разработанный Cisco. Найти корректное определение одного из основных параметров DUAL, feasible distance (FD), оказывается подчас непростой задачей.